12
edits
Changes
→Other comments
* in the old dbm days, secmod.db was combined in the softoken PKCS #11 module primarily because that's where the dbm code was. With the sql database, it's possible to separate the moduleDB load from softoken. That might be a good plan for 3.13, removing yet more code from the cryptographic boundary of NSS.
* IMO, hardcoding magic behavior like this (open two locations when only one path was passed into the API) is a mistake. It's obvious that /etc/pki/nssdb is "special" and the API ought to highlight this fact. There should be a distinct API call for initializing the system default location, separate from the call for accessing a user-specified configuration, and every app/caller that needs instance-specific configuration should explicitly call both APIs.
The overall feel I get from reading this page is still that NSS was designed for single-user client usage, and server/library usage are a hasty afterthought. The only way to get away from the NSS_Shutdown problem is by introducing new APIs that are specifically designed for these new use cases, and punting backward compatibility. (I.e., stability of apps that only use the existing APIs cannot be guaranteed in this new environment.)
E.g.: use a distinct API call to initialize the default /etc/pki/nssdb database. Refcount all DB opens. Use a distinct API call to close each database, instead of a one-call-destroys-everything Shutdown. Use an atexit() or similar destructor to make sure that Shutdown on hardware tokens occurs if an app exits without cleaning up nicely. (You're still SOL if you get SIGKILL but you always were...)
