Open Bug 283665 Opened 20 years ago Updated 2 years ago

Bad error mapping from PKCS11 to NSS error codes

Categories

(NSS :: Libraries, defect, P3)

Tracking

(Not tracked)

People

(Reporter: nelson, Unassigned)

Details

NSS has a single error mapping table that it uses to map all PKCS11 errors
into NSS errors, regardless of the context of the failure.  This leads to 
some pretty useless/meaningless error mappings.  The NSS error codes should
be helpful to the user to know what went wrong, but often are not.  

For example, when a key cannot be imported due to an invalid value of oen
of the key's attributes, the module returns CKR_ATTRIBUTE_VALUE_INVALID
which NSS maps to SEC_ERROR_BAD_DATA instead of to SEC_ERROR_BAD_KEY.
In the context of importing a key, error codes should clearly indicate
a key problem, not a "data" problem.

NSPR solves this problem in its mapping of Unix error codes to NSPR error
codes by having separate mapping functions for different contexts.  A unix
error code will map to different NSPR errors depending on the context in 
which it occurs.  For example, in mozilla/nsprpub/src/md/unix/unix_errors.c 
we see that ETIMEDOUT maps to PR_IO_TIMEOUT_ERROR in some contexts and to
PR_REMOTE_FILE_ERROR in others.

NSS should do something similar, so that it can produce more useful error
codes.  Bad error codes hurt US (the NSS developers), because when users
cannot undersand the error codes, they ask us, which consumes our time.
It would be better for us and for our users for NSS to give out better 
error codes.
QA Contact: bishakhabanerjee → jason.m.reid
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.