[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen J. Turnbull
Subject: Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5
Date: Wed, 05 Feb 2014 17:13:29 +0900

Ted Zlatanov writes:

 > Right.  Shelling out

Fine point: no need for a shell, and it's almost certainly preferable
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.

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

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

Not relevant in the sense that it could be done with an anonymous
popup that says it's from Emacs, too.

 > Trusting loosely coupled components is standard industry practice.

Trust and coupling are not in any particular relationship.  Viz. the
fundamental design of Qmail and Postfix, which are two MTAs designed
by acknowledged security experts.

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

Stupid, no, but there's a lot of evidence that they are ignorant
(including many developers incorporating security features in their
products), and that even experienced experts are oversight- and even
mistake-prone in this area.  Do you claim that that evidence is no
longer relevant?

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

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

To summarize, I just don't find your arguments that GPG is a poor
solution from the security viewpoint plausible.  OTOH, libnettle would
be a neat feature, but I personally don't find a compelling necessity
for it.  larsi's use case seems pretty strong to me, but not enough so
that I'd go against Stefan's gut feeling on the matter.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]