Bug 466313

Summary: NSS_Init makes life difficult for SSL-using libraries
Product: [Fedora] Fedora Reporter: Dan Winship <danw>
Component: nss_compat_osslAssignee: Orphan Owner <extras-orphan>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: a.badger, adam, dpal, rcritten, rrelyea, scottt.tw
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 347491    

Description Dan Winship 2008-10-09 17:51:54 UTC
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.)

Comment 1 John Poelstra 2008-10-10 23:33:44 UTC
This bug has been triaged

Comment 2 Dan Winship 2010-01-08 23:05:35 UTC
This is apparently being worked on (or at least, thought about) upstream:

https://wiki.mozilla.org/NSS_Library_Init
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Comment 3 Bob Relyea 2010-01-08 23:35:23 UTC
NSS library init is live in NSS 3.12.5.

Comment 4 Adam Goode 2011-08-12 14:37:51 UTC
Is this issue now resolved?

Comment 5 Rob Crittenden 2011-08-16 12:56:23 UTC
It has not been addressed within nss_compat_ossl.

Comment 6 Dmitri Pal 2011-08-17 21:06:38 UTC
(In reply to comment #4)
> Is this issue now resolved?

Is this a priority? Would you be able to help?

Comment 7 Fedora Admin XMLRPC Client 2011-08-24 18:22:44 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Fedora Admin XMLRPC Client 2015-04-29 22:35:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Fedora Admin XMLRPC Client 2015-05-26 11:03:06 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Fedora Admin XMLRPC Client 2015-05-26 11:26:49 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Fedora Admin XMLRPC Client 2015-05-26 15:33:05 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.