Closed
Bug 297734
Opened 20 years ago
Closed 19 years ago
root cert module does not support OS locking mode
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.11
People
(Reporter: julien.pierre, Assigned: wtc)
References
Details
I found that the NSS root cert PKCS#11 module does not support initialization with CK_C_INITIALIZE_ARGS containing NULL pointers to lock functions, and the CKF_OS_LOCKING_OK flag set . This needs to be fixed in order for bug 292809 to be resolved .
Reporter | ||
Comment 1•20 years ago
|
||
I started implementing a patch, which makes libnssckfw.a use NSPR functions directly, essentially deleting most of nsprstub.c . But libnssckbi.so is linked with libnssbase.a, which uses many NSPR functions . Instead of calling the stub implementations, they will now call the real NSPR functions. This would violate case #3 for C_Initialize - when the caller provides the lock and does not set CKF_OS_LOCKING_OK , ie. the same problem that softoken has (see 297735) . I'm not crazy about fixing case #2 and breaking case #3 at the same time. We should figure out a solution to make both work, at least for the root cert module . One of them would be to recompile libnssbase to use stub functions instead of calling the NSPR functions directly when linking it to the root cert module.
Assignee | ||
Comment 2•20 years ago
|
||
Julien, you can implement the four Mutex callbacks that use OS locks in libnssckfw.a. This solutions avoids linking libnssckfw.a with NSPR. The four mutex callbacks are small so the code duplication with NSPR is small.
Reporter | ||
Comment 3•20 years ago
|
||
Wan-Teh, I can appreciate that it's only 4 functions, but the platform-specific code would have to be included for all of them right into the ckfw source . NSPR supports a lot of platforms. It seems like doing it this way would be a maintenance burden for NSS going forward . I was thinking of perhaps dynamically loading the PR_Lock / PR_Unlock / PR_NewLock / PR_DestroyLock symbols from nssckfw when they are needed . But this also requires dlopen / dlsym / dlclose equivalents . It's still 3 platform-specific functions to implement . But perhaps these are less variable accross platform than the lock functions ? One solution might be to include the body of code for PR_LoadLibrary / PR_FreeLibrary / PR_FindSymbol in an NSPR header file (with an optional macro defined), so that NSS could include it, rather than duplicate it. I wouldn't suggest that we do this for the lock functions of course, only for those 3 symbols . This could also be useful for other libraries that don't want to implicitly depend on the NSPR DSOs . Thoughts ?
Assignee | ||
Comment 4•20 years ago
|
||
The OS locking code only has a few possible implementations. pthread mutex covers all Unix/Linux platforms and Mac OS X. Adding Windows will achieve your goal in practice. Adding OS/2 and BeOS will achieve complete platform coverage.
Reporter | ||
Updated•19 years ago
|
Priority: -- → P2
Version: unspecified → 3.10
Assignee | ||
Comment 5•19 years ago
|
||
We plan to fix this bug as a by-product of fixing bug 302416. We will link the root cert module with NSPR shared/dynamic libraries and make it support only single-threaded mode and OS locking mode. See bug 302416 comment 26.
Assignee: julien.pierre.bugs → wtchang
Depends on: 302416
Assignee | ||
Comment 6•19 years ago
|
||
Fixed as a by-product of fixing bug 302416.
Status: NEW → RESOLVED
Closed: 19 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
•