OpenSSL 1.0.0 released [LWN.net]

OpenSSL 1.0.0 released

Posted Mar 29, 2010 22:20 UTC (Mon) by quotemstr (subscriber, #45331)
Parent article: OpenSSL 1.0.0 released

Great. Now the OpenSSL people just need to relicense the code under something GPL-compatible.

to post comments

OpenSSL 1.0.0 released

Posted Mar 29, 2010 22:41 UTC (Mon) by flewellyn (subscriber, #5047) [Link] (8 responses)

GNU TLS exists for this reason.

OpenSSL 1.0.0 released

Posted Mar 29, 2010 23:20 UTC (Mon) by foom (subscriber, #14868) [Link] (2 responses)

Too bad GNU TLS is totally broken.

http://lists.debian.org/debian-devel/2010/03/msg00298.html

OpenSSL 1.0.0 released

Posted Mar 30, 2010 0:10 UTC (Tue) by cowboy (guest, #2231) [Link] (1 responses)

And then, there is this

http://www.openldap.org/lists/openldap-devel/200802/msg00...

Lastly (from my perspective) is the fact that GNU TLS fails to interoperate with many other servers (TLS 1.1 negotiation), and with many of the OpenSSL to GNU TLS patches (like to OpenLDAP), you can't always get things talking nicely :(

Just say no

OpenSSL 1.0.0 released

Posted Mar 30, 2010 3:06 UTC (Tue) by foom (subscriber, #14868) [Link]

Be careful when quoting a message from 2 years ago it its criticism is still valid. That one looks like
it is not.

http://www.gnu.org/software/gnutls/manual/html_node/X_002...

Function: int gnutls_x509_crt_set_subject_alt_name (gnutls_x509_crt_t crt,
gnutls_x509_subject_alt_name_t type, const void * data, unsigned int data_size, unsigned int flags)

OpenSSL 1.0.0 released

Posted Mar 30, 2010 3:49 UTC (Tue) by njs (subscriber, #40338) [Link] (4 responses)

Also NSS, which the Fedora people seem to be attempting (slowly?) to standardize everything on: http://fedoraproject.org/wiki/FedoraCryptoConsolidation

OpenSSL 1.0.0 released

Posted Mar 30, 2010 10:12 UTC (Tue) by buchanmilne (guest, #42315) [Link] (3 responses)

But it is not suitable for software which must simultaneously support client
and server operation, as it (apparently) only supports one SSL context.

This is the reason it hasn't been considered for OpenLDAP.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 18:46 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

Yet NSS is the crypto library used in the 389 Directory Server (aka Redhat Directory Server, formally Fedora Directory Server; derived from the netstcape directory services...). So somehow it's appropriate for that LDAP server even though the OpenLDAP folks do not like it.

NSS is also FIPS140-2 certified. The only other open source software that has gotten it is OpenSSL. So that makes it appropirate for any sort of institution that has to work with the USA federal government. Not terribly important for most people, but at least you know it's been verified for correctness by third party experts and this certification is critically important for companies like Redhat.

it's very mature library. It's been around for a long time. Supports hardware acceleration, smart cards, and a bunch of other little things that OpenSSL does not. (and there, are, of course things that OpenSSL supports that NSS does not)

The license is a lot better, also. NSS is triple licensed under the MPL, GPL, and LGPL giving it superior license compatibility over OpenSSL or GnuTLS.

It also has very nice python bindings that Redhat put a lot of effort into. This allows you to use Python with SSL support in GPL'd applications... which by default you technically cannot since python's normal ssl stuff is OpenSSL derived.

There is some detail in the API design that is suppose to be superior for application developers. Something about keeping the crypto aspect of things out of the hands of the application developers... which is generally a good thing since app developers rarely get that sort of thing correct. But I don't know enough to really understand everything and talk about it much. Just what I've read in the past.

Personally, I feel if everybody decided to follow Fedora's example and standardize around a NSS then we'd all be better off. Having lots of different crypto libraries is just asking for trouble since it's surprisingly difficult to get crypto right.

But actually I do end up using OpenSSL a lot more then NSS because of the nice command line client and ample online examples of OpenSSL usage. So I am not trying to knock the work the OpenSSL folks have put into it.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 18:54 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Red Hat is leading this effort but it is worth noting that LSB is standardizing
on NSS as well

https://ldn.linuxfoundation.org/node/5576

FIPS and GPL compatibility being two important driving factors.

OpenSSL 1.0.0 released

Posted Mar 31, 2010 15:14 UTC (Wed) by TRS-80 (guest, #1804) [Link]

OpenLDAP ships client libraries as well as an LDAP server, and that's where the problem with NSS is. What happens when a program links against NSS and also links against libnss-ldap that's linked with NSS? NSS' lack of context support rules it out. The OpenLDAP server can also be an LDAP client through back-ldap and so has the same problem. It's not like the NSS developers don't realise this is a problem, they've defined functions to allow different contexts, but the functions are stubs that just return.

OpenSSL 1.0.0 released

Posted Mar 29, 2010 23:12 UTC (Mon) by efexis (guest, #26355) [Link]

Yay, freedom, to do as we tell you.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 2:17 UTC (Tue) by busterb (subscriber, #560) [Link] (5 responses)

I've a big fan of http://www.polarssl.org/ - GPL, SSL 3.0 and TLS 1.0/1.1 seem
to work well enough, and the code could not be easier to read and use.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 3:07 UTC (Tue) by foom (subscriber, #14868) [Link] (4 responses)

Available under GPLv2 only: basically useless for a distro.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 3:20 UTC (Tue) by foom (subscriber, #14868) [Link]

Sorry, read too quickly. They also have a "license exemption" for FOSS licenses.

http://www.polarssl.org/license_exception

But, that has two conditions that still make it still unusable by a linux distro as a replacement for
GNUTLS/OpenSSL:

> A FOSS application developer ("you" or "your") may distribute a Derivative Work provided that
> you and the Derivative Work meet all of the following conditions:

[...]

> 4. You distribute Independent Works in object code or executable form with the complete
> corresponding machine-readable source code on the same medium and under the same FOSS
> license applying to the object code or executable forms;

Not the case for a Linux distro: source is usually not distributed on the same CD as binaries.
Furthermore, source code for many programs is available under different (less restrictive) terms
than the object code (because the object code is only available under the intersection of the
licenses for all pieces of source code.

> 5. All works that are aggregated with the Program or the Derivative Work on a medium or
> volume of storage are not derivative works of the Program, Derivative Work or FOSS
> Application, and must reasonably be considered independent and separate works.

Not the case for a Linux distro: in fact many such Derivative Works are derivative works of other
such Derivative Works.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 20:30 UTC (Tue) by samroberts (subscriber, #46749) [Link] (2 responses)

Most distros are chock full of GPLv2 licensed code, what is the problem here?

OpenSSL 1.0.0 released

Posted Mar 30, 2010 20:58 UTC (Tue) by Darkmere (subscriber, #53695) [Link] (1 responses)

Libraries licensed under GPL-2 are somewhat bad and a problematic situation for distributors.

OpenSSL 1.0.0 released

Posted Mar 30, 2010 21:36 UTC (Tue) by foom (subscriber, #14868) [Link]

And we're not just talking about *any* old library here: SSL is used (many times indirectly) in
programs of just about every license imaginable. So, if you're going to choose an SSL
implementation to link against for another infrastructure library which is permissively licensed
(say, libldap, or libcurl), you really don't want to choose one which is only usable by GPLv2
programs.

BTW, insane thing I just noticed: gnutls is available under the LGPL, but gnutls' openssl
compatibility layer (libgnutls-openssl) is available under the GPL. Crazy...