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

[Daiki Ueno <ueno@gnu.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

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

Isn't it because those platforms provide more advanced memory management
mechanisms than Emacs?

> 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 didn't mean one-time use of password like that.  I was talking about
the risk of keeping passwords in Emacs memory for a long time, as string
copy also happens in GC.

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

Elisp access to crypto primitives doesn't help this either.  It must be
entirely written in C then, including IMAP protocol support.

By the way, speaking of IMAP, SASL-based authentication is currently
written in Elisp here and there.  Perhaps it could be rewritten with
libgsasl?  I think this is a concrete use-case, much convincing than
Elisp access to crypto primitives.
-- 
Daiki Ueno