LibNSS advantages

Posted Feb 17, 2011 3:26 UTC (Thu) by ringerc (subscriber, #3071)
In reply to: LibNSS advantages by foom
Parent article: PostgreSQL, OpenSSL, and the GPL

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.

to post comments

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.