Bug 162913 – [GTK] CryptoDigest implementation depends on GnuTLS with LGPLv3+/GPLv2+ deps

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Olivier Blin]

Since r197940, CSP depends on CryptoDigest to have support for inline script and inline style hashes.
On WebKit GTK and EFL platforms, this is implemented with GnuTLS (see also r197575).

Though, GnuTLS pulls the nettle and gmplib libraries, which are dual-licensed under LGPLv3+ and GPLv2+ in their current versions.
This makes WebKit GTK effectively LPGLv3+ when gnutls in linked in.

[Olivier Blin]

On #webkitgtk+, we considered the following crypto libraries:

- openssl
* actively maintained
* usually available on desktop and embedded systems
* ASM optimizations
* hardware acceleration and secure certificates management through custom engines
* Apache license is not compatible with GPLv2, unless an exception is added by GPL users

- libgcrypt
* actively maintained
* usually available on Linux systems (pulled by systemd, cryptsetup)
* optimizations: ASM for many platforms (including AArch64), ARMv7/NEON
* requires the small libgpg-error library
* license is OK: library is LGPLv2, only tools are GPLv2

- NSS
* actively maintained
* usually available on desktop systems
* no ASM optimizations for digest and AES (to confirm?)
* requires the NSPR platform abstraction library
* MPL 2.0 license should be ok

- forking coreutils' functions for checksums tools
* license is GPLv2, not usable for WebKitGTK+

- mhash
* no release since end of 2008
* written Nikos Mavroyanopoulos (original GnuTLS author) and Sascha Schumannby
* packaged in Linux distributions, but seldomly used
* license is OK: LGPLv2

- sphlib
* no clear view on maintenance, no public repo
* seldomly used
* written for the French Government
* license is OK, MIT-like

- libtomcrypt
* no activity since 2010
* written in C, no ASM optimizations
* license is OK, public domain

[Konstantin Tokarev]

>no activity since 2010

This is not true, look at git repository. It is very active

[Michael Catanzaro]

Note that we seem to agree that libgcrypt is the best option if we add a new dependency.

However, Zan notes that WTF has its own implementation of SHA-1, and we could probably roll our own SHA-2 as well, which together would be sufficient to replace all GnuTLS functionality used by CryptoDigest. This would probably be ideal.

We also considered mbed TLS (formerly Polar SSL), and discarded it as an option as it uses Apache license.

(In reply to comment #1)
> - openssl
>
> * Apache license is not compatible with GPLv2, unless an exception is added
> by GPL users

Note: the OpenSSL license is not compatible with GPLv2 unless the system library exception is used, and Debian has declined to declare OpenSSL a system library. OpenSSL is planning to change its license in the future to Apache v2, which is also not compatible with GPLv2.

(In reply to comment #2)
> >no activity since 2010
> 
> This is not true, look at git repository. It is very active

libtomcrypt has activity in its git repository, but appears to have no releases since 2010. At least we failed to find them anywhere.

[Carlos Alberto Lopez Perez]

(In reply to comment #3)
> Note that we seem to agree that libgcrypt is the best option if we add a new
> dependency.
> 
> However, Zan notes that WTF has its own implementation of SHA-1, and we
> could probably roll our own SHA-2 as well, which together would be
> sufficient to replace all GnuTLS functionality used by CryptoDigest. This
> would probably be ideal.
> 


Here are c++ public-domain implementations of sha-2 https://github.com/kalven/sha-2

Avoid adding an extra dependency will be my preferred option. Specially if is only for something as simple as computing sha1/sha2 hashes.

Perhaps the SubtleCrypto code can be replace with a libgcrypt implementation. 

And then the code for CSP code can use the hash functions from SubtleCrypto if this was selected at build time. Otherwise it can fall back to our simple/non-optimized internal implementations of sha-1/sha-2.

[Olivier Blin]

(In reply to comment #4)

> Perhaps the SubtleCrypto code can be replace with a libgcrypt
> implementation. 
>
> And then the code for CSP code can use the hash functions from SubtleCrypto
> if this was selected at build time. Otherwise it can fall back to our
> simple/non-optimized internal implementations of sha-1/sha-2.

CSP is using CryptoDigest directly.
Maybe the CryptoAlgorithmHMAC platform-specific implementations in Source/WebCore/crypto should be replaced by a common implementation that uses CryptoDigest.
This is what is done in Source/WebCore/crypto/algorithms/ implementations already.

By the way, it looks a bit weird to have platform specific implementations of crypto in both and Source/WebCore/crypto/<platform> (SubtleCrypto) and Source/WebCore/platform/crypto/<platform>/ (CryptoDigest)

I am going to propose both a libgcrypt implementation and an OpenSSL implmentation of CryptoDigest.

Another alternative would be to resurrect the gcrypt backend in gnutls, since performance improved since its removal (nettle was preferred at the time).
See https://www.gnupg.org/blog/20131215-gcrypt-bench.html

[Zan Dobersek]

(In reply to comment #5)
> 
> I am going to propose both a libgcrypt implementation and an OpenSSL
> implmentation of CryptoDigest.
> 

This makes most sense to me. OpenSSL implementation should probably be kept downstream until WPE begins the upstream process.

> Another alternative would be to resurrect the gcrypt backend in gnutls,
> since performance improved since its removal (nettle was preferred at the
> time).
> See https://www.gnupg.org/blog/20131215-gcrypt-bench.html

Ideally we'd be able to do that, but it's a decision that should be made by the GnuTLS maintainers.

[Michael Catanzaro]

(In reply to comment #0)
> This makes WebKit GTK effectively LPGLv3+ when gnutls in linked in.

Turns out we misunderstood how these licenses work. WebKitGTK+ is still effectively LGPLv2+ and we have no upstream problem. You just have to ensure you comply with the terms of either LGPLv3+ or GPLv2+ with respect to the dependent libraries. This is a problem for certain companies that do not wish to do so, so we still want to get rid of the GnuTLS dependency, but it no longer seems urgent.

[Konstantin Tokarev]

In my understanding, GPL2-only (not 2+) software still has a license conflict when LPGL3 dependency is present in combined work, though that may not be a big problem

[Carlos Alberto Lopez Perez]

(In reply to comment #7)
> (In reply to comment #0)
> > This makes WebKit GTK effectively LPGLv3+ when gnutls in linked in.
> 
> Turns out we misunderstood how these licenses work. WebKitGTK+ is still
> effectively LGPLv2+ and we have no upstream problem. You just have to ensure
> you comply with the terms of either LGPLv3+ or GPLv2+ with respect to the
> dependent libraries. This is a problem for certain companies that do not
> wish to do so, so we still want to get rid of the GnuTLS dependency, but it
> no longer seems urgent.

You can also comply with LGPLv2+ alone depending on how you build WebKitGTK+.

GnuTLS can be built with libgmp-4.2.1 and nettle-2.7.1. If you opt to do this, then everything is LGPLv2+.

[Olivier Blin]

(In reply to comment #9)

> GnuTLS can be built with libgmp-4.2.1 and nettle-2.7.1. If you opt to do
> this, then everything is LGPLv2+.

Technically, you can indeed, but gmp 4.2.1 is from 2006, with potential security issues.

[Konstantin Tokarev]

Also, according to compiler researcher John Regehr, old GMP versions are likely to have undefined behavior cases: https://twitter.com/johnregehr/status/748238295230988288 (which may result in miscompilations and yes, more potential for security issues)

[Carlos Alberto Lopez Perez]

Well, nothing of that is our problem.

We are LGPLGv2+ and no one of the libraries we link to is LGPLv3+. Fact: GnuTLS which is also LGPLGv2+.

GnuTLS can (in practice) end being LGPLGv3+ depending on how you build it. 
But that is not our problem. Really.

I agree with trying to replace the GnuTLS dependency.

But keep in mind that this is not going to 100% fix the issue.

Even if we replace the GnuTLS dependency for the crypto code, you will probably end using it anyway via libsoup -> glib-networking -> gnutls backend.

And I don't know in which state of quality are the other glib-networking backends.

So in the end I think this can be summarized as:

 * We are not depending on any LGPLv3+ library. But one of our dependencies (GnuTLS) has decided to depend on a LGPLv3+ library. Fortunately this is still something you can work-around by using old nettle and old libgmp if you care about this issue.

 * We will try to avoid using GnuTLS because of the above. But keep in mind that even when we end doing that, you can end anyways using GnuTLS without realizing this via the glib-networking TLS backend dependency.

So in the end this (carefully selecting which libraries and versions go into the build) is something the distributor should care about, and not us.

[Olivier Blin]

(In reply to comment #12)

> Even if we replace the GnuTLS dependency for the crypto code, you will
> probably end using it anyway via libsoup -> glib-networking -> gnutls
> backend.

Licensing concerns may be a bit different for glib-networking, since gnutls and its deps are not linked directly, but loaded as a dynamic plugin.

>  * We will try to avoid using GnuTLS because of the above. But keep in mind
> that even when we end doing that, you can end anyways using GnuTLS without
> realizing this via the glib-networking TLS backend dependency.

Ok, I will propose a gcrypt backend, covering CryptoDigest and HMAC.

> So in the end this (carefully selecting which libraries and versions go into
> the build) is something the distributor should care about, and not us.

Right

[Carlos Alberto Lopez Perez]

(In reply to comment #13)
> (In reply to comment #12)
> 
> > Even if we replace the GnuTLS dependency for the crypto code, you will
> > probably end using it anyway via libsoup -> glib-networking -> gnutls
> > backend.
> 
> Licensing concerns may be a bit different for glib-networking, since gnutls
> and its deps are not linked directly, but loaded as a dynamic plugin.
> 

IANAL, but I really think that linking directly a library or loading a dynamic plugin on the same process at run-time makes no difference regarding whether your program is a combined/derived work or not of the library/plugin.

However, there is a difference if the plugin is executed as another process and you use IPC to communicate with it. But if your program loads the plugin directly and does function calls to it, then your program is a combined/derived work of such plugin/library.

https://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

Which now makes me wonder ..... 

Since the UIProcess and the WebProcess are separated programs and GnuTLS is only used on the WebProcess perhaps we don't have any issue at all.

?

[Olivier Blin]

(In reply to comment #14)

> Since the UIProcess and the WebProcess are separated programs and GnuTLS is
> only used on the WebProcess perhaps we don't have any issue at all.
> 
> ?

And same for glib-networking + GnuTLS which is in the NetworkProcess.

[Michael Catanzaro]

> Since the UIProcess and the WebProcess are separated programs and GnuTLS is
> only used on the WebProcess perhaps we don't have any issue at all.

Like I said: there's no issue for us because there's no license pollution, regardless of which processes are involved.

And there is still an issue for distributors who do not want to comply with LGPLv3+, regardless of which processes are involved.

I don't think it really requires much further discussion; we've agreed we want to switch to libgcrypt.

[Michael Catanzaro]

WebKit no longer links directly to GnuTLS