HsOpenSSL license problimatic

[joeyh]

Hey Andrew! We were looking into getting http-streams packaged for Debian, and noticed that there is a bit of a licencing gotcha with its use of openssl.

The problem is that the openssl license is not compatible with licenses like the GPL. Now, HsOpenSsl and http-streams are under licenses which do not have any compatability problems with the openssl license. You're in the clear there.

But, suppose I have an existing GPL code base (I do), and I'd like to make it use http-streams (I would), and other people have contributed patches (they have) and I don't require license assignment (I don't). It's legally impossible for me to link my GPLed code with openssl and distribute the result. To make it legal, I'd need to change my code's license, adding a special license exception to the GPL to allow linking it with openssl. But since I am not the sole copyright holder, I can't do that, and would have to track down everyone who had improved my code, and get them to agree too.

Looking at HSOpenssl, its own documentation encourages using TLS instead. If you could switch to TLS, these nasty license problems would go away. Note that http-conduit uses TLS, apparently with success!

I think we could package http-streams for Debian regardless. But if I can't use it in my existing code, some of the motivation is gone..

[istathar]

@joeyh You have to convince @gregorycollins that tls is safe. There has been no cryptanalysis audit of it by anyone who knows what they're doing. That trumps licencing concerns I'm afraid. Personally, on that basis alone, I'll stick with openssl. As for the headline, I fixed that depressed-pho/HsOpenSSL#20 .

AfC

[mightybyte]

It's not just @gregorycollins. If you care about how secure your crypto is, cryptanalysis peer review trumps just about everything. That's probably why OpenSSL is so ubiquitous. Also, after looking at their website, it sounds like OpenSSL is not necessarily incompatible with the GPL.

[joeyh]

Here's a fairly good summary of the issues with the OpenSSL license,
which any use of HsOpenSSL inherits despite its own public domain licensing.

https://people.gnome.org/~markmc/openssl-and-the-gpl.html

It should be possible to use gnutls instead of OpenSSL. I'm not sure if
the haskell binadings for gnutls cover enough ground to use it for https
yet.

see shy jo

[mightybyte]

But GnuTLS uses the GPL license. With the Snap Framework, we prefer BSD3. If you put yourself in our shoes, it should be pretty clear that OpenSSL would be preferred over GnuTLS. Yes, the all-Haskell tls package with it's BSD3 license would be better still, but security is more important to us.

Andrew, of course, is free to do anything he wants with http-streams. But keep in mind that it is built on the Snap ecosystem and also uses BSD3.

[gregorycollins]

Anecdotal data point: at one point our SSL support was based on GnuTLS but I ripped it out and replaced it with OpenSSL. With GnuTLS the snap-server was segfaulting somewhere inside the crypto library, and after carefully going through the gnutls Haskell binding code I couldn't find an error there that would explain it.

[joeyh]

I know that a segmentation fault bug was fixed in version 0.1.4 of the
haskell gnutls binding. (I reported that one to John with a test case
and he tracked it down.) Of course it's impossible to tell if that was
the same bug.

see shy jo

[istathar]

I've been writing Open Source for a long time and using the GPL since 1996. I have, however, gotten tired of licencing debates. I (reluctantly) decided to BSD3 my first Haskell library because, frankly, that's what the entire .hs ecosystem uses (and so does the entire .js world, to their notable success). So, fine. Honestly though, while I believe in and support the GPL, if DFSG has a problem with openssl's licencing then that's a bug against openssl and you need to take it up with them. I chose BSD so I wouldn't have to have this damn conversation anymore; openssl is open and free software and that's good enough for me.

I would happily consider hsgnutls, but, um, that package hasn't seen an update since 2008 and doesn't build GHC 7. wtf? Surely that's not what you're recommending. I assume I'm missing something.

/me thinks Haskell needs a security team. Well, we do once we actually get repeatable builds and stability when we finally fix cabal to escape dependency hell.

AfC

[joeyh]

http://hackage.haskell.org/package/gnutls has been updated in the past
year and builds with current ghc.

see shy jo

[istathar]

@joeyh I'm not sure

"This is a pre-alpha, almost useless release; You almost certainly don't want to depend on this"

at the package description for gnutls is all that encouraging! More importantly, it has no haddock at all, which doesn't help with beginning to get a feel for what it does or how well we can expect it to do it.

This is all a mess, which makes me sad.

AfC

[istathar]

So the state of this is:

1. tls package has not had a security audit that anyone in industry feels comfortable with. It also lacks infrastructure to deal with the system /etc/ssl/certs database, leaving individual implementations to hack this in themselves.

2. gnutls package is lacking documentation, and doesn't appear to have any sophistication about certificate validation or anything else for that matter.

If either of these conditions changes I will be happy to re-open this.

AfC