Re: [Emacs-diffs] trunk r115420: Use libcrypto's checksum implementations if available, for speed.

[Paul Eggert]

Ted Zlatanov wrote:

> Stefan's objection is not to the default or to the licensing but to the
> code complexity and growth.

I thought that the objection was to the dependency.  If it's to complexity,
then this depends on whether one is worried about overall complexity
(Emacs + gnulib + libcrypto) or about complexity of Emacs maintenance alone.
If the former, obviously including libcrypto complicates things.
If the latter, it'll complicate Emacs proper slightly to make it harder
for builders to configure Emacs to use libcrypto; obviously no big deal,
if that's the way we want to go.

> what's the rationale for depending on
> libcrypto (Apache licensed AFAICT) when, as we've mentioned here, GnuTLS
> (through libnettle+libhogweed) offers very similar facilities from a GNU
> project?

Performance is the only reason for depending on libcrypto.
Until recently libcrypto was quite a bit faster, but
a few days ago (prompted by the recent gnulib change!) libnettle's
performance was improved on x86-64 (the platform I typically use)
and now libnettle is now 15% slower than libcrypto on Intel,
20% faster on AMD.  See Niels Möller note in
<http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00030.html>.

I don't know GnuTLS and nettle well.  Does GnuTLS expose MD5, SHA256, etc.
hash functions as part of its API?  If so, presumably there'd be little
objection to having Emacs use those, as Emacs already depends on GnuTLS.
If not, then Stefan has already objected to depending on libnettle directly,
for reasons I don't understand; also, Eric Blake has mentioned
certification-based objections to direct use of libnettle as opposed
to indirect use via GnuTLS; see
<http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00034.html>.