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

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 05 Feb 2014 17:13:29 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 
On Wed, 05 Feb 2014 17:19:13 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

SJT> Ted Zlatanov writes:
>> Right.  Shelling out

SJT> Fine point: no need for a shell, and it's almost certainly preferable
SJT> not use a shell.

>> to an external binary every time you want to verify a package's
>> signature or want to encrypt/decrypt/sign data makes perfect sense.

SJT> Obviously not perfect, since at least one person in the world doesn't
SJT> get it.  Nevertheless, the GPG developers apparently think it does
SJT> make good sense, since they've made a point of making it difficult to
SJT> do otherwise.

DU> At least it works at acceptable performance now.

It's not acceptable to me, but then again I'm not a crypto/security-expert.

>> Blindly entering your passphrase in an anonymous popup that says
>> it's from the GnuPG agent is how things are done.

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

DU> This could be fixed.  Sounds definitely easier than importing plenty of
DU> crypto primitives from a C library.

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

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

DU> Didn't I post a link to the idea of this loose coupling?  It is mainly
DU> for security reasons.  For example, there's usually a limit of secure
DU> memory and it makes sense to do all the secret key operation in a
DU> minimal core (gpg-agent) to utilize it.

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.

>> Forcing users to do all of that, or "no encryption for you" is for
>> their own good, on every platform where Emacs runs, from Android to
>> W32 to Mac OS X to many flavors of Unix.  Users are just too stupid
>> to decide these things on their own.

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.

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.  It doesn't mean I don't
understand what EPA/EPG and GnuPG offer, or that I don't like them, or
that I don't use them.

>> Is that how experts with a crypto/security background do it?

SJT> Some of them (the GPG developers) do, for sure.

DU> Better than letting you write encryption code for me.

I plan to write integration code mostly, which is not as risky.  But you
make a good point: *you're* the only one writing such code for Emacs
users.  Could you be biased in favor of your own code?

DU> Case study (sorry Jose):
DU> https://lists.gnu.org/archive/html/bug-recutils/2012-04/msg00001.html

DU> I can easily imagine you will make similar (or more serious) mistakes
DU> here and there, once crypto primitives are available.

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

Ted