Closed
Bug 66490
Opened 25 years ago
Closed 20 years ago
New NSS library contains stubs for NSPR functions
Categories
(NSS :: Libraries, enhancement, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.11
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.
| Assignee | ||
Comment 1•25 years ago
|
||
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
Comment 2•25 years ago
|
||
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
| Assignee | ||
Updated•24 years ago
|
Priority: P1 → P2
| Assignee | ||
Updated•24 years ago
|
Target Milestone: 3.3 → 3.4
| Assignee | ||
Comment 3•24 years ago
|
||
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Updated•24 years ago
|
Target Milestone: 3.4 → 4.0
| Assignee | ||
Comment 4•23 years ago
|
||
Assigned the bug to myself, targeting NSS 3.9,
priority P2.
Assignee: relyea → wtc
Target Milestone: 4.0 → 3.9
| Assignee | ||
Updated•22 years ago
|
Target Milestone: 3.9 → ---
| Reporter | ||
Updated•20 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
| Assignee | ||
Comment 5•20 years ago
|
||
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: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.11
You need to log in
before you can comment on or make changes to this bug.
Description
•