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
        NSS_init()/SSL_library_init()

(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
       $SSL_DIR explicitly.

       (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.)