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)

3.9.7
x86
Windows XP

Tracking

(Not tracked)

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.
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.