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

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > 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."

Ted, there is no "secure core" in an Emacs Lisp application.  That was
the main point of the defadvice.  If *your* Lisp program can invoke a
password popup, so can *my* sleazebag defadvice.

 > SJT> As applications, yes.  But who cares?  Try, "do they expose the crypto
 > SJT> facilities to users of their platform (eg, Javascript)?"
 > 
 > Well, the Java VMs expose javax.crypto...

If that's analogous to libnettle, that's good enough for me for this
particular analogy.  (I'll take your word for it.)

 > 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.

Security is all about what *could* happen if you're not careful.  If
you aren't already thinking carefully about that, I don't understand
why you're doing this!