Open
Bug 299291
Opened 19 years ago
Updated 2 years ago
NSS has 2 functions to fetch a cert from nickname which don't quite do all the required work.
Categories
(NSS :: Libraries, defect, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: rrelyea, Unassigned)
Details
As part of fixing Bug 298955 , it was noted that there were two functions to fetch a cert with a nickname. One function takes a CERTDBHandle but no password argument (CERT_FindCertByNickname), the other takes a password arg (PK11_FindCertByNickname), but no CERTDBHandle. The former is the "higher" level function which calls the latter, but it does not have a password arg to pass, so NULL is passed. If the cert lives on a token that is not marked as publically readable (a.k.a. friendly), and is not logged in, and the application's password prompt requires a password arg, the resulting search will fail. Applications need a definative function it can call that will reliably return the certificate if it exists. Bug 298955 has one example on how this new function could be implemented. Other solutions include renaming the current CERT_FindCertByNickname and make it take a password arg, which it could pass to the PK11_FindCertFromNickaname, and creating a new CERT_FindCertByNickname to call our renamed function passing NULL for the password arg. The existing FindCert[By/From]Nickname functions should be marked as depricated and new apps should use the new function.
Updated•18 years ago
|
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Updated•18 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•