[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NaCl support for Emacs

From: Ted Zlatanov
Subject: Re: NaCl support for Emacs
Date: Mon, 09 Jan 2012 12:26:44 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

On Mon, 09 Jan 2012 19:09:34 +0200 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> 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

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

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

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

The NaCl API is simplest and it seems to be really fast, that's what
attracted me to it.

I agree, though, that libnettle or libgcrypt may be a better choice.
NaCl is not required at all.  I simply didn't think of libnettle and

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

Unfortunately there's no way to use GPG's functionality without invoking
GPG itself, so libgcrypt is no better than libnettle in this context.

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

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

OK, I agree.  I'll look at libgcrypt and libnettle and see if they are
easily exposed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]