Closed Bug 66490 Opened 19 years ago Closed 15 years ago
New NSS library contains stubs for NSPR functions
Presently, NSS contains several libraries that implement PKCS#11 modules. Today, each of these libraries contains duplicate source code to implement "stubbed" versions of certain NSPR functions used by NSS code, functions that we believe cannot be used as-is in PKCS#11 modules because PKCS#11 modules cannot force applications to use NSPR's threading. Recently we added even more stubs to NSS. We added duplicate implementations of NSPR functions for doing run-time dynamic loading of shared libraries. I propose that all these "stubs" for NSPR functions be gathered into a single library in NSS, lib/stubs, instead of being duplicated in verious other libraries.
I would like to broaden the scope of this bug to include thw following two issues. 1. Is it okay now to link these loadable PKCS#11 modules with NSPR shared libraries (including libnspr4, libplc4, and libplds4)? 2. If the answer is no, we should also use stubs for the NSPR functions in libplc4 and libplds4 rather than linking with the static libplc4 and libplds4 libraries because NSPR static libraries are not supported and starting in the next NSPR release (4.2) I will not build static NSPR libraries. Right now these PKCS #11 modules are linked with the static libplc4 and libplds4 libraries and use stubs for the functions in libnspr4. I want to have these issues resolved in NSS 3.3, hence the target milestone 3.3 and priority P1. Bob, I am assigning this bug to you now because you are the best person to answer these questions. Once you decide what we should do, we can reassign this bug to someone else to implement the solution.
Assignee: wtc → relyea
Priority: -- → P1
Target Milestone: --- → 3.3
OK, so the issues here are basically: 1) we cannot include nspr4 in PKCS #11 modules because of threading/nspr mismatch issues. (PKCS #11 modules are included in applications with old version of NSPR running. Multiple different copies of NSPR cause certain problems (like crashing). 2) we can link plc4 and plds4 as long as plc4 and plds4 do not make direct calls into nspr4. If they do we can't use them. Our current solution is to statically link those two libraries we can use, which forces the libraries to use the stub functions we have included in our PKCS #11 library. bob
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Assigned the bug to myself, targeting NSS 3.9, priority P2.
Assignee: relyea → wtc
Target Milestone: 4.0 → 3.9
QA Contact: bishakhabanerjee → jason.m.reid
This bug has been resolved in NSS 3.11. In NSS 3.11 we removed the FORTEZZA PKCS #11 modules and changed the built-in root cert module to link with the real NSPR shared libraries. So NSS no longer needs stubs for NSPR functions.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.11
You need to log in before you can comment on or make changes to this bug.