Wherein I argue for the inclusion of libnettle in Emacs 24.5

[Lars Ingebrigtsen]

Ted posted a patch to give Emacs native encryption support a few months
back:

http://permalink.gmane.org/gmane.comp.encryption.nettle.bugs/736

It was rejected because Stefan thinks that we should wait until we have
FFI support in Emacs, and it should be implemented that way.

I'm going to argue that 1) I don't think we should wait, and 2) FFI
isn't that great, anyway.

We Shouldn't Wait
=================

Using encryption from Emacs is pretty awkward now.  GnuPG 2.0 has
shifted to a model where the applications themselves can't feed any
passwords into the GnuPG programs -- they always ask for the passwords
themselves, or rely on the user having started a gpg daemon that will
handle the password storage.

I've started writing a new thing for Gnus that is basically Dropbox +
newsrc storage via IMAP:

http://lars.ingebrigtsen.no/2014/02/01/emacs-cloud/

The idea is that you should be able to say `M-x gnus' on a brand new
laptop, answer a few questions, and then your entire setup is
replicated.  And you can move back and forth between different machines
pretty seamlessly.

This means pushing data that might be sensitive over the network, and
storing it in IMAP folders.  So we need encryption.  Since we're pushing
updates pretty regularly, we need to encrypt smaller chunks.  Asking for
a password every single time would make this impossible to use.

If we required the user to run a gpg daemon, that would help, but it's
awkward to have to do that, and it's not supported on all OS-es.

If Emacs had native support for encryption, this would be trivial to handle.

And in these days of greater security vigilance (not only the NSA stuff,
but an ever-larger number of data breaches), not providing proper
encryption to these data stores would be irresponsible, I think.

Of course, the Emacs Cloud stuff isn't the only thing that could do with
encryption.  The original use case Ted had -- storing credentials in a
more opaque manner -- is still as relevant as ever.

And I'd just like to remind everybody here that adding encryption
support won't bring in any further library dependencies.  This is all
already brought into the Emacs builds by the gnutls support.  So it's
all "for free".

FFI Isn't That Great Anyway
===========================

My experiences with FFI comes from using it under proprietary Common
Lisp environments.  There it's absolutely necessary.

But it's necessary because it's a proprietary environment.  If we're in
the Free World, as we definitely are in Emacs, linking with the
libraries using the normal ways and means are always superior.

If you're interfacing with a library like crypt(3), FFI is fine.  You
have a function that takes a couple of strings, and you get one string
back.  All FFI converters do that fine.  But, unfortunately, that's
often all they do.

Real C libraries often have gnarly error reporting conventions,
callbacks, weird data structures, etc, etc.  In my Common Lisp
experiences, I've sometimes found that I can either write a 200 line
monstrosity in the FFI framework, or I can write a seven line C program
that calls the library it's supposed to be called.

So Stefan suggest just making these C shims be part of the FFI thing,
and we'll just distribute packages with some C code included.  Which
would then have to be compiled.

It's a possibly solution, but many systems don't ship with C compilers,
so this would drastically reduce the uptake of the packages.

There are other problems with allowing "third party" binary packages
into Emacs, too.  We'll get further incomprehensible segfaults reported,
which we probably can't do much about.

Emacs doesn't have a formal stable "internal ABI", anyway.  Experiences
from other projects that have tried to allow binary plugins (like gcc)
seem to show that that's not the way to go, either.  If you allow binary
modules to be inserted, they aren't that useful unless you lock down
your internal ABIs.  And I think that would be a hindrance to further
Emacs development.

So, To Sum Up
=============

1) Carthage should be destroyed
2) Emacs should support encryption as soon as possible to best handle
   the security needs of our users
4) FFI is nice for proprietary products, but sub-optimal for free software


-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/