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

[Ted Zlatanov]

On Fri, 07 Feb 2014 18:07:35 +0900 Daiki Ueno <address@hidden> wrote: 

DU> Ted Zlatanov <address@hidden> writes:
>> What do you think happens when you open a .gpg file using GnuPG
>> externally, even disregarding the OS channels traveled?  That data is
>> certainly not safe from defadvice.

DU> Didn't I ever say:

DU> - Once an attacker successfully takes over your desktop session, he can
DU>   do almost everything.  We can't do much on that situation.  Why don't
DU>   you lock the screen before leaving?

We could at least try to process data in a place where ELisp can't
access it.

DU> - More possible threat is inspecting persistent data (e.g. core files on
DU>   a disk attached to a stolen note PC).  GnuPG is designed to be secure
DU>   against this, using "secure core".

I don't agree with the EPA/EPG coupling to GnuPG but admire the design
of both sides.  GnuPG is a great program that, due to the client/agent
design, is hard to use securely as an API.  As proof, consider the Java
libraries to implement OpenPGP internally (BouncyCastle).  Similar
situation in Go (http://godoc.org/code.google.com/p/go.crypto/openpgp).

Is Emacs so different from those platforms, given applications like Gnus
and Magit and eww?

DU> - On the other hand, Emacs copies small strings around.  If passwords
DU>   (normally not too long) are managed poorly in Emacs, they might appear
DU>   repeatedly in a core file, when it crashes.

Right, regardless of EPA/EPG's behavior, you *still* need passwords in
the clear to open an IMAP connection, for instance.  I feel that, unless
we wish to blame the user for not locking their desktop, Emacs should at
least try to protect such passwords in its own "secure core."  It's
surely possible and, I honestly believe, a worthy goal.  I think for
that goal to happen *some day* we need the crypto primitives
GnuTLS/libnettle/libhogweed provide, so we don't have to write our own.

>> Emacs as a whole could use a way to hide "data not intended for direct
>> user inspection" better, and provide for a "tainting" trace of data
>> (to use the Perl term).

DU> Interesting.  Any prior art on that area?  I haven't heard the word
DU> "tainting" used in that way.  Isn't it for preventing untrusted data
DU> being injected to, say, SQL?

Here I meant it in the sense of "knowing when a data token has been
touched by a Lisp function" with the assumption that Lisp code is
inherently unsafe.

(Perl's "taint" traces data obtained externally.  It's remarkable
because it imposes some security on top of a very liberal language, a
lot like Lisp in fact.  See http://perldoc.perl.org/perlsec.html for
further details.)

Ted