Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency as well. That's a key requirement to me personally, because otherwise it will not interoperate with Mozilla/Seamonkey, and right now that's my primary goal for this work.
The -compat code is LGPL. I'm considering copying the ciphersuite handling and a few other pieces out of there, directly into our tree. There's a lot of other baggage in the compat library we don't need, and there's some OpenSSL emulation that would interfere with the NSS code we already have. Any problem with excerpting the bits we need?
It's been a few months since I last looked at this and it took me a while to remember all the issues surrounding it...
There are two major problems with the current MozNSS support in HEAD:
- It does no initialization of its own. This works with Seamonkey/Thunderbird
because the main app has already initialized the NSS library; libldap just uses the state that's already there. Code to initialize properly when NSS hasn't already been initialized still needs to be written. 2) It cannot shutdown safely. This is a weakness in the NSS API that was discussed at length in the Mozilla newsgroups. Unfortunately that discussion went nowhere. (The NSS_Shutdown() function tears down the library unconditionally; if there were multiple callers of the library and one of them shuts down because it's going away, all of the other callers lose the library too.)
It appears that not much progress has been made on the latter problem. Here's a relevant wiki
Unfortunately this aspect of NSS is still too broken for it to be used safely in libldap, when other apps also use NSS directly.
There's still no technical advantage to using this over OpenSSL, and there's still a significant usability/app-safety disadvantage to adopting it. (GnuTLS at least offers TLS1.2 support, which neither OpenSSL or MozNSS do yet. Both OpenSSL and MozNSS have FIPS-140 validations, but FIPS mode is incompatible with the way most existing software uses these libraries, so it's kind of a moot point.)