Bug 466313
| Summary: | NSS_Init makes life difficult for SSL-using libraries | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Winship <danw> |
| Component: | nss_compat_ossl | Assignee: | Orphan Owner <extras-orphan> |
| Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | 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 | ||
This bug has been triaged 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 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. |
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.)