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

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

[Stefan Monnier]

>   Use libcrypto's checksum implementations if available, for speed.

I'm tired of adding more static dependencies to Emacs, and have already
explained that these should be added via an FFI instead.

For that reason, I think this patch should be reverted.


        Stefan

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

[Paul Eggert]

Stefan Monnier wrote:
> I'm tired of adding more static dependencies to Emacs

OK, I've disabled libcrypto by default, in trunk bzr 115446.
This means Emacs will not use libcrypto unless the person who
runs 'configure' specifically asks for it.

Ripping out all possibility of using libcrypto will take more
work.  I'm not sure a scorched-earth policy like that is
worthwhile but will undertake it if that's the consensus.

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

[Ted Zlatanov]

On Mon, 09 Dec 2013 18:50:57 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> Stefan Monnier wrote:
>> I'm tired of adding more static dependencies to Emacs

PE> OK, I've disabled libcrypto by default, in trunk bzr 115446.
PE> This means Emacs will not use libcrypto unless the person who
PE> runs 'configure' specifically asks for it.

PE> Ripping out all possibility of using libcrypto will take more
PE> work.  I'm not sure a scorched-earth policy like that is
PE> worthwhile but will undertake it if that's the consensus.

The dependency remains in the code even if it's off by default.  I think
Stefan's objection is not to the default or to the licensing but to the
code complexity and growth.  In other words, the policy is not to scorch
the earth but to wait for the spring FFI cleanup :)

But speaking of licensing, 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?  I'm not against libcrypto at all, to be clear, but I think you
should have an answer to the licensing question because project
decisions (notably the use of Bazaar) have often considered it.

Ted

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>.

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

[Ted Zlatanov]

On Tue, 10 Dec 2013 09:55:15 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> Ted Zlatanov wrote:
>> Stefan's objection is not to the default or to the licensing but to the
>> code complexity and growth.

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

I'll let Stefan answer; I just mentioned my impression.  See the
discussion I linked earlier for his original responses.

>> 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?

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

That's good news! :)

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

OK, so libnettle+libhogweed expose all the hash, HMAC, and cipher
functionality you'll need.  SHA-*, AES*, RSA, DSA... too many to list.
I got to RSA and DSA when I heard from Stefan, so I stopped at that
point, but the symmetric ciphers, hashing, and HMAC functionality is
integrated.  You can see my patch at the URL of the original discussion
I posted.

The GnuTLS passthrough functions are fairly new.  See the tables in
http://gnutls.org/manual/html_node/Using-GnuTLS-as-a-cryptographic-library.html
for the full list of supported functionality.  I think they support
enough to get us going.

Ted

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

[Stefan Monnier]

>> I'm tired of adding more static dependencies to Emacs
> OK, I've disabled libcrypto by default, in trunk bzr 115446.
> This means Emacs will not use libcrypto unless the person who
> runs 'configure' specifically asks for it.

No, I want to revert the previous commit, not just "disable it by
default".  It's going in the wrong direction.

> The dependency remains in the code even if it's off by default.  I think
> Stefan's objection is not to the default or to the licensing but to the
> code complexity and growth.  In other words, the policy is not to scorch
> the earth but to wait for the spring FFI cleanup :)

Thanks, Ted, that's pretty much it,


        Stefan

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

[Paul Eggert]

> the policy is not to scorch
> the earth but to wait for the spring FFI cleanup

It's a bit of both, no?  Scorch the earth now,
and wait for spring later.  We do this sort of thing in
Southern California all the time, except that we
wait for fall, when the rains start.

Anyway, I reverted that change in trunk bzr 115454, so
that there's no longer the possibility of linking with
libcrypto.  This is not a 100% revert since gnulib has
moved on, but it should address the key point here.

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

[Stefan Monnier]

> libcrypto.  This is not a 100% revert since gnulib has
> moved on, but it should address the key point here.

Thank you,

I encourage people to work on an FFI so that we can add such support in
a modular way.


        Stefan