SHA, MD, and openssl

SHA, MD, and openssl

[Eli Zaretskii]

I see that Emacs got support for SHA/MD checksums from openssl.
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?

Re: SHA, MD, and openssl

[Paul Eggert]

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?

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

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

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

Re: SHA, MD, and openssl

[Eli Zaretskii]

> Date: Sun, 08 Dec 2013 13:01:40 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> 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?
> 
> I'm not aware of any patent issues for SHA or MD5.

I meant openssl as a whole.

> As for as license, Emacs is linking against a library
> that is normally distributed with the major components of
> the operating system, so that part of the GPL applies.

What about systems where openssl is not normally present out of the
box?  Aren't we encouraging people to install it?

Re: SHA, MD, and openssl

[Paul Eggert]

Eli Zaretskii wrote:
> I meant openssl as a whole.

Emacs trunk won't let Emacs users use openssl as a whole,
only the SHA and MD5 part of libcrypto, so any patent
concerns with other parts of openssl should not be an
issue.

> What about systems where openssl is not normally present out of the
> box?  Aren't we encouraging people to install it?

Not particularly.  The build will work just fine without openssl,
and no part of the documentation or installation instructions
encourages people to install openssl.

If this turns into a real problem, we can change the installation
instructions to mention that the libcrypto part is intended to be
used only on platforms where libcrypto is normally distributed
with the major components of the operating system.

Re: SHA, MD, and openssl

[Ted Zlatanov]

On Sun, 08 Dec 2013 13:01:40 -0800 Paul Eggert <eggert@cs.ucla.edu> 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

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

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

Ted

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

Re: SHA, MD, and openssl

[Ted Zlatanov]

On Sun, 08 Dec 2013 17:46:09 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sun, 08 Dec 2013 13:01:40 -0800 Paul Eggert <eggert@cs.ucla.edu> 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

Re: SHA, MD, and openssl

[Stefan Monnier]

> It's a very similar commit to my proposed patch in that it brings in
> a new library dependency.

Indeed, it suffers from the same problem.


        Stefan

Re: SHA, MD, and openssl

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

What it is normally distributed thus, the system library
exception applies.  But it would be good to verify that that is
generally true.  Do users ever install these libraries separately
from the major system components?

    > What about systems where openssl is not normally present out of the
    > box?  Aren't we encouraging people to install it?

    Not particularly.  The build will work just fine without openssl,
    and no part of the documentation or installation instructions
    encourages people to install openssl.

This is a red herring.  There is nothing wrong with installing
OpenSSL.  It is free software, after all.  As a general matter, we
encourage people to install OpenSSL.

However, when they install it, the GPL3 system library exception does
not cover it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: SHA, MD, and openssl

[Stephen J. Turnbull]

Richard Stallman writes:

 > Do users ever install these libraries separately from the major
 > system components?

I have to ask, does this question make sense any more?  Users install
*everything* "separately" these days.  Nobody unpacks a tarball into /
and reboots -- you install a tiny system (which in the days of
floppy-based installs included a crippled libc, and even today many
installers seem to use busybox instead of a suite of separate
utilities), which then starts acquiring packages (kernel, libc, Emacs,
NCSA httpd, Mosaic, oops-i'm-showing-my-age.deb, ...) and installing
them one-by-one.  What's the distinction between OpenSSL and Emacs
when installed by a list-of-packages-driven package manager?

Again, if a security bug is discovered in OpenSSL, *everybody in the
world* downloads and installs *just* that upgrade.  And *almost*
everything is distributed "with" the "major components".  Even Debian
provides installers for non-free software such as Adobe Flash I
believe.  Although Debian does provide a clear distinction on license
grounds by using "free", "nonfree", and "contrib" subdistros, most
other distros don't bother AFAIK.  Nor does "library" help much when
you're talking about Emacs, which provides almost all of the services
(ie, excepting raw memory allocation) to libraries that the programs
traditionally called "operating systems" do.  In some sense, anything
Emacs links to becomes part of the E-OS!

Perhaps you can draw a fine distinction, but I suspect that's going to
cause more confusion than it's worth.  GNU/Linux (as in the Debian
"free" distribution) is a functionally complete operating system,
including advanced GUI display.  Unless you make a clear definition,
developers are going to assume that anything "in" a distro that is a
"library" is a "system library" per GPL, and therefore linkable with
GPL programs.  But that won't fly (per your decision on X/Open Motif
as distributed by Red Hat, TurboLinux, and SuSE (IIRC) a decade ago).

With respect to OpenSSL itself, I have trouble seeing it as a system
library in the sense intended by the GPL.[1]  Secure communication is
an application everybody wants these days, but it is not a necessary
part of a host's operating system, not even as much so as Motif was.
It's very painful if you can't get it GPL-compatibly.  But that's
never been an excuse before.  You wouldn't even allow a *separate
binary* to be required for secure communication functionality in Emacs
(original TRAMP + SSHv1, granted that SSHv1 was non-free, it *was* a
separate binary, so by the usual "exec boundary" didn't infringe).


Footnotes: 
[1]  AIUI, the intention was to allow Emacs (for example) to link to
a proprietary system libc.  Otherwise Emacs couldn't be distributed
*at all* with proprietary systems, which is clearly a Bad Thing from
the point of view of encouraging such distributors to free themselves.

Re: SHA, MD, and openssl

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

     > Do users ever install these libraries separately from the major
     > system components?

    I have to ask, does this question make sense any more?

Of course it makes sense.  And it has to be asked, because this is the
condition that the GPL's rule depends on.

Can we argue that OpenSSL normally accompanies Linux?
It seems like a stretch.  Does Android include OpenSSL?
What about the Busybox/Linux system used in many embedded devices,
does that contain OpenSSL?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: SHA, MD, and openssl

[Paul Eggert]

Richard Stallman wrote:
> Does Android include OpenSSL?

Yes; at least, it's in the core source code (I just downloaded it)
and seems to be used in several places.  (I don't normally develop
for Android; I merely did a quick look.)

> What about the Busybox/Linux system used in many embedded devices,
> does that contain OpenSSL?

Busybox itself doesn't have OpenSSL.  Busybox and Linux are
normally combined with other stuff in embedded devices.  I'm
by no means expert in this area, but somewhat-at-random I
looked at Tiny Core Linux <http://www.tinycorelinux.net/>.
It includes OpenSSL in its Tiny Core Extensions package, which
appears to be its only plausible environment that Emacs could run in.

The pattern, I expect, is that if it's reasonable to consider
running Emacs on a GNU/Linux-based platform, these days openssl
is most likely a standard part of that platform.

Re: SHA, MD, and openssl

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    The pattern, I expect, is that if it's reasonable to consider
    running Emacs on a GNU/Linux-based platform, these days openssl
    is most likely a standard part of that platform.

The actual criterion is

      The "System Libraries" of an executable work include anything, other
    than the work as a whole, that (a) is included in the normal form of
    packaging a Major Component, but which is not part of that Major
    Component, and (b) serves only to enable use of the work with that
    Major Component, or to implement a Standard Interface for which an
    implementation is available to the public in source code form.

I don't think OpenSSL is included in the normal form of
packaging Linux, and I don't think it satisfies (b) either.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: SHA, MD, and openssl

[Paul Eggert]

[Adding bug-gnulib to CC.  This discussion no longer directly affects
Emacs, since I removed the libcrypto support from Emacs yesterday
<http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/115454>.  Gnulib
still has support for linking to libcrypto, though, so it's still
relevant for gnulib.  This email thread starts at
<http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00252.html>.]

On 12/11/2013 07:13 AM, Richard Stallman wrote:

> I don't think OpenSSL is included in the normal form of
> packaging Linux

I'm afraid you've lost me.  Did you mean that Linux is the "Major
Component" as described in the GPL?  If so, that doesn't sound right,
as the code we're talking about is crypto hash code, which doesn't
need to interface to the Linux kernel at all.  It's written in pure
C and/or assembly code, with no Linux system calls.

The Major Component here is not the Linux kernel; it's cryptographic
services, which these days are a major essential component of many
operating systems, including common GNU/Linux distributions.
Obviously one can build a GNU/Linux system without crypto, just as one
can build one without a windowing system, but nevertheless crypto is a
major essential component for many systems, just as windowing is.

> I don't think it satisfies (b) either.

I don't see why not, for the crypto hash functions we're talking
about.  MD5, SHA256, etc. are all interfaces that are official
standards defined by recognized standards bodies, and implementations
for them are available to the public in source code form.

Re: SHA, MD, and openssl

[Pádraig Brady]

On 12/11/2013 06:54 PM, Paul Eggert wrote:
> [Adding bug-gnulib to CC.  This discussion no longer directly affects
> Emacs, since I removed the libcrypto support from Emacs yesterday
> <http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/115454>.  Gnulib
> still has support for linking to libcrypto, though, so it's still
> relevant for gnulib.  This email thread starts at
> <http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00252.html>.]

coreutils still enables use of openssl libcrypto where available.
I suspect this is more of an advantage to coreutils than to emacs,
due to the provision of bulk data processing functionality through
md5sum and sha1sum etc.

> On 12/11/2013 07:13 AM, Richard Stallman wrote:
> 
>> I don't think OpenSSL is included in the normal form of
>> packaging Linux
> 
> I'm afraid you've lost me.  Did you mean that Linux is the "Major
> Component" as described in the GPL?  If so, that doesn't sound right,
> as the code we're talking about is crypto hash code, which doesn't
> need to interface to the Linux kernel at all.  It's written in pure
> C and/or assembly code, with no Linux system calls.
> 
> The Major Component here is not the Linux kernel; it's cryptographic
> services, which these days are a major essential component of many
> operating systems, including common GNU/Linux distributions.
> Obviously one can build a GNU/Linux system without crypto, just as one
> can build one without a windowing system, but nevertheless crypto is a
> major essential component for many systems, just as windowing is.
> 
>> I don't think it satisfies (b) either.
> 
> I don't see why not, for the crypto hash functions we're talking
> about.  MD5, SHA256, etc. are all interfaces that are official
> standards defined by recognized standards bodies, and implementations
> for them are available to the public in source code form.

So practically I see the openssl crypto libs as ubiquitous and the chosen
interface used to expose _system_ specific checksum functionality,
down to specific sha instructions or coprocessing units etc.
I don't see using these interfaces as detrimental to the essential freedoms,
but instead _significantly_ improving the performance and thus the
utility of these core GNU tools. If we don't use these system interfaces
we'll just be sidelined for something that does.

Now we could clean room implement equivalent operations for the many disparate
systems out there, however it's worth noting there is significant advantage in
hardware vendors consolidating around a single implementation, and openssl
is where that's at currently.  I'm not discounting that a GPL equivalent
might arise, but until that happens we should use the current system interfaces.
BTW openssl.org says it's OK to use these interfaces from GPL software
due to the system lib exception: http://www.openssl.org/support/faq.html#LEGAL2

thanks,
Pádraig.

Re: SHA, MD, and openssl

[Glenn Morris]

Pádraig Brady wrote:

> BTW openssl.org says it's OK to use these interfaces from GPL software
> due to the system lib exception: http://www.openssl.org/support/faq.html#LEGAL2

But some people disagree with that interpretation, eg:

http://lwn.net/Articles/428111/
http://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html

Re: SHA, MD, and openssl

[Stephen J. Turnbull]

Pádraig Brady writes:

 > BTW openssl.org says it's OK to use these interfaces from GPL software
 > due to the system lib exception: http://www.openssl.org/support/faq.html#LEGAL2

AFAIK that's legally irrelevant.[1]  The FSF (as copyright holder in
the GPL itself!) can comment on the intended meaning of terms such as
"system libs" in the license, as can the licensor (copyright holder)
of a *specific* GPLed software that might be linked with OpenSSL
(although they might need to make an explicit exception that would
apply only to that software, see below).  A third party who
distributes GPLed software linked with OpenSSL would have to be backed
by a court if the copyright holder disagreed.  And IMHO openssl.org's
opinion would probably be admitted only as "amicus", and only given
attention if their lawyer were really famous in the field.

Cf. Linus's famous "interpretation" of the GPL as allowing non-free
drivers to be loaded by the kernel.  Only Linus could do that; not the
driver vendors, not third parties like distros.  And in the end, the
FSF's opinion overruled that "interpretation", and Linus was forced to
make the exception explicit (in the same way that Bison's parser
skeleton code gets an explicit and limited exception).


Footnotes: 
[1]  In the U.S., and the usual IANAL TINLA caveats apply.

Re: SHA, MD, and openssl

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    The Major Component here is not the Linux kernel; it's cryptographic
    services, which these days are a major essential component of many
    operating systems, including common GNU/Linux distributions.

I don't think "cryptographic services" is a system component.
It is a category of uses of software, not even a collection
of programs, let alone a single component.

    > I don't think it satisfies (b) either.

    I don't see why not, for the crypto hash functions we're talking
    about.  MD5, SHA256, etc. are all interfaces that are official
    standards defined by recognized standards bodies, and implementations
    for them are available to the public in source code form.

MD5 and SHA256 are not interfaces.  They are algorithms.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: SHA, MD, and openssl

[Pádraig Brady]

On 12/12/2013 10:15 AM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     The Major Component here is not the Linux kernel; it's cryptographic
>     services, which these days are a major essential component of many
>     operating systems, including common GNU/Linux distributions.
> 
> I don't think "cryptographic services" is a system component.
> It is a category of uses of software, not even a collection
> of programs, let alone a single component.
> 
>     > I don't think it satisfies (b) either.
> 
>     I don't see why not, for the crypto hash functions we're talking
>     about.  MD5, SHA256, etc. are all interfaces that are official
>     standards defined by recognized standards bodies, and implementations
>     for them are available to the public in source code form.
> 
> MD5 and SHA256 are not interfaces.  They are algorithms.

But SHA1 and SHA256 are commonly available accelerated in hardware.
For this very small subset of routines should we not consider
libcrypto as a system library to these hardware specific interfaces.

thanks,
Pádraig.

Re: SHA, MD, and openssl

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    But SHA1 and SHA256 are commonly available accelerated in hardware.
    For this very small subset of routines should we not consider
    libcrypto as a system library to these hardware specific interfaces.

This has nothing to do with what we "should consider".
It is a legal criterion stated in the GPL.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: SHA, MD, and openssl

[Pádraig Brady]

On 12/13/2013 12:21 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     But SHA1 and SHA256 are commonly available accelerated in hardware.
>     For this very small subset of routines should we not consider
>     libcrypto as a system library to these hardware specific interfaces.
> 
> This has nothing to do with what we "should consider".
> It is a legal criterion stated in the GPL.

OK.

Note I've changed coreutils not automatically
use these routines where available.

thanks,
Pádraig.

Re: SHA, MD, and openssl

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Note I've changed coreutils not automatically
    use these routines where available.

That's good.  But I think it should not have any code to use OpenSSL.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: SHA, MD, and openssl

[Rüdiger Sonderfeld]

On Sunday 08 December 2013 13:01:40 Paul Eggert wrote:
> As for as license, Emacs is linking against a library
> that is normally distributed with the major components of
> the operating system, so that part of the GPL applies.

The license comments on gnu.org explicitly say, it is not compatible with the 
GPL

>     The license of OpenSSL is a conjunction of two licenses, one of them
>     being the license of SSLeay. You must follow both. The combination
>     results in a copyleft free software license that is incompatible with
>     the GNU GPL. It also has an advertising clause like the original BSD
>     license and the Apache 1 license.
>     
>     We recommend using GNUTLS instead of OpenSSL in software you write.
>     However, there is no reason not to use OpenSSL and applications that
>     work with OpenSSL.

https://www.gnu.org/licenses/license-list.html#OpenSSL

That would mean distributions like Debian would not be able to ship Emacs with 
OpenSSL support.  E.g., Debian's git package does not support SSL because of 
this problem.  Using GNUTLS would also make more sense because it is already 
an (optional) dependency of Emacs.

Regards,
Rüdiger