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)
NEW
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.
| Reporter | ||
Updated•20 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
| Reporter | ||
Updated•19 years ago
|
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
| Reporter | ||
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
•