Red Hat Bugzilla – Bug 466313
NSS_Init makes life difficult for SSL-using libraries
Last modified: 2015-05-26 11:33:05 EDT
If a library (as opposed to an application) wants to use nss_compat_ossl (or NSS directly for that matter), it has to decide whether to:
(a) call NSS_init()/SSL_library_init() itself, and tell it where to
find the certificate db
(b) require the calling application to have already called
(a) clearly won't work, because there could be multiple SSL-using libraries in the application, and they can't each demand that their own certificate store be used. Also, the current version of NSS doesn't support certificate db locking, so when you have two applications using the same SSL-using library running at the same time, they can't both use the same certificate db.
(b) also doesn't work because it breaks in the face of dlopen. Eg, it seems silly to say that gnome-panel needs to link against nss_compat_ossl and call SSL_library_init(), because it's possible that the user may have a shared-library panel applet that uses nss_compat_ossl. (It's not enough for the app to just set $SSL_DIR either, since nss_compat_ossl's SSL_library_init() isn't thread-safe on the first call.)
I can think of three fixes:
1. Make NSS not keep global state, but instead have context objects like
OpenSSL and GnuTLS do, that keep track of what databases are being used,
so different parts of the application can use different databases if
they want to. (Yeah, this would be a huge amount of work and would
totally break the NSS API.)
2. Make nss_compat_ossl autogenerate a certificate db name based on
the application name if $SSL_DIR is not set, and encourage
nss_compat_ossl users to use this feature rather than setting
(I'm pretty sure there's some way we can find out the process
name on Linux and use that to generate the cert db name. This might
not work on other POSIX systems, but it's not clear to me if we
care whether or not nss_compat_ossl works anywhere but Fedora?)
3. Use a single system-wide (per user) certificate directory and have
all apps use it. This would require waiting for the version of NSS
with shared cert dbs
(Saying "all apps that could potentially load an SSL-using library need to set $SSL_DIR" seems like just a more obnoxious version of #2 and not really worth doing.)
This bug has been triaged
This is apparently being worked on (or at least, thought about) upstream:
NSS library init is live in NSS 3.12.5.
Is this issue now resolved?
It has not been addressed within nss_compat_ossl.
(In reply to comment #4)
> Is this issue now resolved?
Is this a priority? Would you be able to help?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.