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

[Stephen J. Turnbull]

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

Of course it isn't.  It's not my claim that GnuPG is clearly more
secure than doing it internally, it's that doing it internally can
only be more secure if GnuPG is more buggy than your code + user code,
and I find that highly unlikely.

 > into a buffer.  This is *not* saying the EPA/EPG design is bad, only
 > that 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).

Sure, it could use those facilities, but it doesn't have them, and
providing them will require completely redesigning internals.

Note that this is not do deny that you can get that security for
*specific* functions using libnettle *if you write them in C*.  What
I'm saying is that exposing them to Lisp means exposing them to Lisp,
and as Emacs is currently composed, that's a security oops assuming
an attack with enough access to pop up a Trojan Horse password havester.

 > OK then, let's hypothesize.  I don't think the presence of these
 > primitives will make the situation worse by flooding us with badly
 > implemented crypto.

I don't think it will be a flood.  I think that it is a hanging noose
that will strangle a trickle of users every day for the indefinite
future, and I don't see a corresponding benefit to outweigh that and
the issues that Stefan raises.

 > Realistically speaking, attacks against Emacs are extremely unlikely
 > unless specific people are targeted.

Exactly.