Tracking bug for landing NSS-glue. Here is the summary from the email I sent to reviewers@mozilla.org: What this is is a crypto glue library that links directly with NSS, instead of using PSM out-of-process. It's partially complete (SSL, some alerts, and the lock icon work), but I'd like to go ahead and check it in, not built by default. The patch I have here does a few things: - adds a --with-security=<foo> switch to configure. The default is "psm". This causes extensions/<foo>-glue to be built, also, security/psm is only built if you have psm as the glue. - removes a reference to nsIPSMComponent in nsHTTPSHandler.cpp. This was introduced fairly recently. We want to avoid using that interface and use nsISecurityManagerComponent instead, this is part of making extensions/* not required to build (bug 18352). It should eventually not be exported. - a couple small cleanups to configure.in and autoconf.mk.in If you want to build this, I wish you luck. Build NSS as described on <http://www.mozilla.org/projects/security/pki/nss/buildnss_31.html>, then run configure --with-security=nss. Make sure you don't accidentely re-checkout mozilla/security on SECURITY_CLIENT_BRANCH over top of NSS (you may want to add 'mk_add_options PSM_CO_TAG=NSS_3_1_RTM' to your .mozconfig). This also does not currently work for separate-objdir builds (it will when I have landed NSS autoconf). Make sure to clobber in extensions/psm-glue! This is unix-only, but windows should be trivial to hook up.

cc'ing some more people. Frank, can you give us any insight into whether checking this in would violate any export regulations? Thanks.

I'm not a huge fan of --with-security=foo, and would rather that we rearchitected into extensions/ssl/{psm,nss,openssl}, making ssl/psm a part of the default extensions. Other than that, I think direct NSS calls are deeply righteous. Go, bryner!

I'm no Frank, but I've been spending many hours with lawyers talking about open-source crypto export issues over the past month, so here's my opinion, for what it's worth: There is no incremental risk in making Mozilla (an open source thing) talk to NSS (an open source thing). All the code is already in the tree to get from Mozilla to SSL-on-the-wire, and we're not adding new ciphers. I recall discussions with Bob during the original NSS release which resulted in a policy that we would only have to re-notify BXA when there was significant cryptographic functionality added, like new ciphers or the ability to plug in new types of crypto. We already have all the pieces here, and I can't see why the BXA would ever care if we made them talk to each other: the Open Cryptographic Interface restrictions don't apply to public-source stuff, were we even making previously-inaccessible things visible to APIs. Maybe someone can make me understand why BXA would be OK with Mozilla -> PSM -> NSS, but not Mozilla -> NSS. If anything, we're making it _less_ flexible and pluggable, right?

Just attached a new patch/tarball. There is virtually no change in the patch file... in the tarball, I have: - added makefile.win's (and verified the whole thing to work on Windows) - incorporated dougt's cleanup suggestions

changing QA contact to junruh@netscape.com

I don't think I'm going to land this patch as such. Instead, this will be folded into the in-process PSM 2.0 work.

Verified per bryner's comment.

Mass changing Security:Crypto to PSM

Mass changing Security:Crypto to PSM