Bug 347691 - Port neon to use NSS library for cryptography
Summary: Port neon to use NSS library for cryptography
Alias: None
Product: Fedora
Classification: Fedora
Component: neon
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
: 346661 (view as bug list)
Depends On:
Blocks: CryptoConsolidation
TreeView+ depends on / blocked
Reported: 2007-10-23 10:21 UTC by Peter Vrabec
Modified: 2014-09-23 20:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2014-09-23 20:03:19 UTC
Type: ---

Attachments (Terms of Use)

Description Peter Vrabec 2007-10-23 10:21:02 UTC
neon should be ported to use NSS library for cryptography.
See the tracking bug for details and links on how it could be done.

Comment 1 Joe Orton 2007-12-04 15:09:53 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.

Comment 2 Bob Relyea 2007-12-04 17:40:29 UTC
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.

Comment 3 Joe Orton 2007-12-04 21:05:59 UTC
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.

Comment 4 Joe Orton 2007-12-04 21:10:07 UTC
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?

Comment 5 Joe Orton 2008-10-20 16:02:09 UTC
*** Bug 346661 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.