Bug 347691
| Summary: | Port neon to use NSS library for cryptography | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Vrabec <pvrabec> |
| Component: | neon | Assignee: | Joe Orton <jorton> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | caolanm, rcritten, rrelyea, tmraz, wtc |
| 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: | 2014-09-23 20:03:19 UTC | 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: | 333741 | ||
|
Description
Peter Vrabec
2007-10-23 10:21:02 UTC
neon has an library-agnostic SSL interface which is currently implemented for both OpenSSL and GnuTLS. To be able to port neon to NSS, NSS needs to be able to work in a mode where a central certificate database is not required. I couldn't work out how to do this with the current API. NSS can be initialized to work without a centralized database. The open ssl compatibility libraries currently uses this method. That being said, doing so can leave the application deficient compared to other applications. Certainly for the first step, that's probably sufficient. As we enable the shared database code, applications that don't play in that shared database will be viewed as deficient or lacking. Can you explain how? I think I was supposed to call NSS_NoDB_Init() to initialize, right? I couldn't see any way to get a CERTCertDBHandle * pointer other than calling the CERT_GetDefaultCertDB() function, so virtually all the state neon needs to manipulate is process-global (e.g. the cert verification callback) - which is not possible for a library interface. The other thing I stumbled on when looking at this was that the export policy would have to be set (again as process-global state) at startup somehow. How would an application (or worse, a library) be expected to decide what export policy to use? Is this supposed to be user-configurable? *** Bug 346661 has been marked as a duplicate of this bug. *** |