Closed Bug 66490 Opened 19 years ago Closed 15 years ago

New NSS library contains stubs for NSPR functions

Categories

(NSS :: Libraries, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nelson, Assigned: wtc)

Details

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
Priority: P1 → P2
Target Milestone: 3.3 → 3.4
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Target Milestone: 3.4 → 4.0
Assigned the bug to myself, targeting NSS 3.9,
priority P2.
Assignee: relyea → wtc
Target Milestone: 4.0 → 3.9
Target Milestone: 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.