| |||||||||||||
LibNSS advantagesLibNSS advantagesPosted Feb 17, 2011 5:58 UTC (Thu) by djao (subscriber, #4263)In reply to: LibNSS advantages by ringerc Parent article: PostgreSQL, OpenSSL, and the GPL
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.
(Log in to post comments)
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.
|
|||||||||||||