PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 19:21 UTC (Wed) by madscientist (subscriber, #16861)
Parent article: PostgreSQL, OpenSSL, and the GPL

The licensing pain is real, for sure, but OpenSSL is really all kinds of bad news. They, or whomever packages them, have absolutely no clue when it comes to shared library support/backward compatibility. What a nightmare.

NSS has one other very significant advantage over GnuTLS and OpenSSL not mentioned in this article: NSS has been blessed as the standard SSL library for LSB. So it will be available on all LSB-compliant installations.

to post comments

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:07 UTC (Wed) by foom (subscriber, #14868) [Link] (3 responses)

It has one significant disadvantage though: almost nothing uses it. :)

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:39 UTC (Wed) by madscientist (subscriber, #16861) [Link] (2 responses)

Well, compared to OpenSSL that might be true but I wouldn't say "almost nothing": all the Mozilla apps obviously use it (Firefox, thunderbird, etc.) Additionally (according to wikipedia) it's used by Chrome, Evolution, Pidgin, OpenOffice, various Red Hat services and various Sun Java services.

Numerically maybe not so impressive but there are some pretty high-profile users there.

The main point, though, is not how many applications use it but the fact that it's (a) correctly backward compatible, and (b) guaranteed to be available on all LSB systems. LSB has a bad rep but it IS a useful baseline that's very nice to rely on, for what it contains, and virtually every serious Linux distro supports it now.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 2:11 UTC (Thu) by jamesh (guest, #1159) [Link] (1 responses)

Furthermore, those applications probably account for the majority of SSL connections established on most people's machines, and the largest number of different servers connected to. So the actual networking code is probably just as robust as OpenSSL.

The main issue is whether the API it provides makes it as easy to integrate into applications as the OpenSSL API does.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:54 UTC (Thu) by lkundrak (subscriber, #43452) [Link]

Well, there is nss_compat_ossl library which implements a subset of openssl API on top of NSS. For most software it takes very little effort to carry them over from openssl, just to be on the safe side.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:35 UTC (Wed) by jengelh (subscriber, #33263) [Link] (3 responses)

>NSS has been blessed as the standard SSL library for LSB.

Being part of some standard won't magically proliferate it.

$ for i in mozilla-nss libgnutls26 libopenssl1_0_0; do rpm --test -e "$i" 2>&1 | pcregrep -o '(?<=$installed$ )\S+' | sort -u | wc -l; done
7
9
63

..I still wait for the day until a "beautiful" API comes around. One that does not hide pointers behind, or use, typedefs, but rather ptrs to <incomplete> structs, does so in lower-case, and also has a prefix of sorts. No library fulfills all of these atm.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:18 UTC (Wed) by madscientist (subscriber, #16861) [Link]

See my above comment. I don't care how many different apps use it... why should that matter? Enough serious applications rely on it to ensure it's not overtly buggy and doesn't contain lots of silly security holes and that's all that's important. Having it part of LSB ensures it will be there, and it will be supported, and it will be backward compatible. That's absolutely critical for those who don't want to be forced to recompile their software for every given distro and distro version.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:59 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

[lkundrak@potwor ~]$ rpm -q --whatrequires libcrypto.so.10 |wc -l
63
[lkundrak@potwor ~]$ rpm -q --whatrequires libnss3.so |wc -l
23

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 1:23 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

This is obviously only applicable to your specific packages installed

LibNSS advantages

Posted Feb 17, 2011 2:56 UTC (Thu) by ringerc (subscriber, #3071) [Link] (8 responses)

There's more than one advantage to NSS.

Unlike OpenSSL and GnuTLS, which are crypto and SSL libraries, NSS is a more complete system with key management support, PKCS#11 support, etc. Rather than apps having to implement all their own key storage and management, they just use the existing libnss database and tools. Best of all, you can have a shared per-user key database, so you can FINALLY avoid having to install your X.509 client certificate manually into every app you use individually.

Key management in Linux is a shrieking nightmare for administrators and no fun for users either. I'd love to see libNSS more widely adopted as it'd really help address that.

LibNSS advantages

Posted Feb 17, 2011 3:14 UTC (Thu) by foom (subscriber, #14868) [Link] (7 responses)

But that doesn't even work between Firefox and Thunderbird!

LibNSS advantages

Posted Feb 17, 2011 3:26 UTC (Thu) by ringerc (subscriber, #3071) [Link] (6 responses)

Neither Firefox nor Thunderbird are set up to use it. Grr!

LibNSS supports a shared SQLite database but nobody wants to agree on where to keep it or whether to use it at all. They all want to stick to how they used to do it. Evolution uses gnutls and its own key management; ff and tbird use private libnss keystores; ssh doesn't even use x.509 certs at all (argh!).

You can enable the shared keystore with one line of code, but nobody's shipping FF and tbird configured that way, let alone adopting it for other apps. Very frustrating. Because few devs use X.509 client certificate infrastructure, it doesn't seem to get much attention/interest.

LibNSS advantages

Posted Feb 17, 2011 5:58 UTC (Thu) by djao (guest, #4263) [Link] (4 responses)

LibNSS supports a shared SQLite database but nobody wants to agree on where to keep it or whether to use it at all. They all want to stick to how they used to do it.

The problem with the shared database is that it breaks backward compatibility. My keys are already in the right configuration file, and the current version of the program that I have already installed expects the key to be in that file. I don't want to be forced to move my keys somewhere else, much less an opaque database. A real UNIX admin prefers flat human-readable text configuration files for any number of reasons. There appears to be no sane way to simultaneously support both in-database keys and configuration-file keys in NSS.

I recently ran into this problem in Fedora's version of openswan, which uses NSS for key storage instead of flat text files like the openswan in every other Linux distribution. This makes key management in Fedora's openswan a huge hassle (you cannot just copy over keys in files). If openswan supported both key databases and keys in files, then there would be no problem. But it doesn't.

LibNSS advantages

Posted Feb 17, 2011 7:10 UTC (Thu) by ringerc (subscriber, #3071) [Link]

The SQLite database replaces the existing nss key3.db and cert8.db files, which are Berkeley DB files. It doesn't replace any text-based configuration mechanism a program may offer for key access.

NSS may be used to load keys from files pointed to by a config file, just as OpenSSL and GnuTLS may. It adds the _option_ of a keystore if you want to use it, but doesn't force it. The issue you ran into sounds like a heavy-handed conversion to nss done by the Fedora folks, rather than an issue inherent to NSS its self.

LibNSS advantages

Posted May 27, 2013 21:10 UTC (Mon) by Jehreg (guest, #91153) [Link] (2 responses)

Let me be clear: This change was done to Openswan by Fedora. Xelerance never forced the use of LIBNSS, as you can see from the authoritative repository held at Github : https://github.com/xelerance/Openswan.git

Xelerance will be issuing a new version (2.6.39) in the next few weeks, and LIBNSS will still not be forced. If Fedora decides to be idiots and force LIBNSS then they will have to answer to their clients, as Xelerance will recommend running other distributions to their clients and partners.

Patrick Naubert
Xelerance Corp.

LibNSS advantages

Posted May 27, 2013 21:31 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

You do realize you are posting to a news story from several years back? If you have a problem with downstream packaging, talk to them, file a bug report or post in their development list and reference that in such conversations.

LibNSS advantages

Posted May 27, 2013 22:27 UTC (Mon) by nix (subscriber, #2304) [Link]

btw, your handle should be spelt 'Jhereg'. :)

LibNSS advantages

Posted Feb 17, 2011 7:16 UTC (Thu) by corsac (subscriber, #49696) [Link]

Evolution uses NSS for all the mail-related code (imap/pop/smtp) and uses the shared nss database (from /etc/pki/nssdb and $HOME/.pki/nssdb). It uses gnutls only through libsoup for http/webdav calendars.