Re: NaCl support for Emacs (was: GnuTLS for W32)

[Eli Zaretskii <eliz@gnu.org>]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Mon, 09 Jan 2012 09:26:21 -0500
> 
> I'm interested in bringing in support for the NaCl cryptographic library
> for Emacs, after 24.1 is out.  There is info on NaCl here:
> 
> http://nacl.cr.yp.to/index.html

Why not libnettle?  We already use it, albeit indirectly, because
latest versions of GnuTLS depend on it.

There's also libgcrypt, which is a dependency of libxml2.

If the functionalities are comparable, bringing in yet another, third,
dependency of the same kind doesn't make sense, IMO.

> My rationale for supporting this library is that it's fast, very simple
> on the client side, and provides good security for arbitrary binary
> payloads.  There are many places within Emacs where that's appropriate,
> whereas heavyweight network-oriented security like GnuTLS is either not
> appropriate or not usable.  An example is EPA/EPG, which currently
> relies on the external GPG utility.  Emacs could provide similar
> functionality (perhaps integrated with EPA/EPG, perhaps standalone)
> without relying on external utilities if it has NaCl support.

Isn't GPG built on top of a library that itself sits on top of
libgcrypt?  If so, it would make sense to use these libraries instead
of yet another one.

With each new external dependency, we (a) increase the number of
external know-how needed to maintain Emacs; (b) increase the
complexity of building a feature-rich Emacs on anything but the few
most popular GNU/Linux systems; and (c) increase the amount of energy
Emacs maintainers/contributors need to spend on external projects --
to build them regularly, participate in discussions, contribute
patches, etc.

I say, let's bring these dependencies and energy spent on other
projects to the absolute minimum, and if we already depend on some
functionality, even if it isn't the latest and the greatest, let's use
it for as long as it satisfies our needs.