LibNSS advantages

LibNSS advantages

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.