Re: SHA, MD, and openssl

[Ted Zlatanov]

On Sun, 08 Dec 2013 17:46:09 -0500 Ted Zlatanov <address@hidden> wrote: 

TZ> On Sun, 08 Dec 2013 13:01:40 -0800 Paul Eggert <address@hidden> wrote: 
PE> Eli Zaretskii wrote:
>>> However, isn't it true that openssl has some legal "issues" with
>>> patents and with its license, and shouldn't we prefer libnettle for
>>> those reasons?

PE> I'm not aware of any patent issues for SHA or MD5.
PE> As for as license, Emacs is linking against a library
PE> that is normally distributed with the major components of
PE> the operating system, so that part of the GPL applies.

PE> It'd make sense for Emacs to use gnutls, nettle, libgcrypt,
PE> etc. if available and if the performance is good.
PE> This has been suggested on the gnulib list and patches
PE> along those lines would be gratefully accepted.
PE> See, for example:

PE> http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00024.html
PE> http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00026.html
PE> http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00036.html

TZ> I wrote the full integration with libnettle+libhogweed as a patch (with
TZ> tests, and bringing in all the interesting ciphers).  It later turned
TZ> out that GnuTLS, already a requirement, exposes all that at the C level
TZ> in passthrough functions, so libnettle and libhogweed are not even a
TZ> requirement.  But that's an implementation detail, since GnuTLS requires
TZ> libnettle and libhogweed anyway.

TZ> Stefan rejected the patch because he wants to move the GnuTLS
TZ> integration to a FFI layer[1].  I don't know when I'll have time to
TZ> implement that myself so any help is welcome.

TZ> [1] https://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00168.html

Stefan, please comment on the commit "trunk r115420: Use libcrypto's
checksum implementations if available, for speed."  It's a very similar
commit to my proposed patch in that it brings in a new library
dependency.  If r115420 is acceptable, I have to ask that you reconsider
my libnettle+libhogweed patch without FFI, as I presented it earlier.

I can try to rewrite it to just use the GnuTLS passthrough functions so
we don't even have new library dependencies, but you previously said
that was not enough.  I think getting it into trunk before the code
freeze, either way, would be really helpful.

I can commit to working on the FFI integration after the code freeze,
for the next release.

Thanks
Ted