some locales will not allow you Unload PKCS#11 Device

RESOLVED FIXED in mozilla17



Security: PSM
8 years ago
a year ago


(Reporter: juanb, Unassigned)



Bug Flags:
blocking1.9.2 -
wanted1.9.2 +
blocking1.9.1 -

Firefox Tracking Flags

(blocking2.0 -, status1.9.1 wontfix)


(Whiteboard: [psm-smartcard])


(1 attachment)



8 years ago
While verifying bug 494899, I noticed some locales like fr or es-es will not allow you to unload a pkcs# device, according to the instructions in bug 494899, comment #18 in the aforementioned bug. This is inconsistent with the behavior in en-US and other locales like de.

You are, however, able to "Load" pkcs#11 devices if you follow that part of the instructions. 

I can see this problem in Fx2.0.0.20, Fx3.0.12pre, Fx3.1b3, and Fx3.5pre, across platforms on at least fr and es-es, but it probably happens with other locales as well.

1. Install the latest Fx3.5pre (fr locale)
2. Go to the equivalent of Options(Preferences), Advanced, Encryption, and click on Security Devices
3. Select the last item in the list and click on "Unload"
4. Click on OK to confirm that you want to unload the module.

Expected: The item disappears from the list.

Actual: You get a dialog saying it was not possible to unload the module.

Given this behavior has been there since Fx2.x times, this will likely not block, but I will request blocking to get it assessed.
Flags: blocking1.9.1?
Not blocking 3.5 final, would take a fix for 3.5.x, should fix for .next.
Flags: wanted1.9.1.x?
Flags: blocking1.9.2+
Flags: blocking1.9.1?
Flags: blocking1.9.1-

Comment 2

8 years ago
It looks like Device Manager have a problem with non-ASCII characters in the name of PKCS#11 devices. Fr and es-ES both have accented characters in their translation of "Builtin Roots Module", removing those fixes this problem.

Using non-ASCII characters in the name of a new module is also problematic. You can add such as module, but the name won't show up in Device Manager and you can't see any of the properties of the module.
Assignee: nobody → kaie
Component: DOM: Mozilla Extensions → Security: PSM
Keywords: intl
QA Contact: general → psm

Comment 3

8 years ago
It appears that the string being passed in goes through truncation via ToNewCString:

I can't find docs for the format expected of the const char *moduleName parameter to SECMOD_AddNewModule but I'm pretty sure we just treats it as a sequence of octets and we could pass a UTF8-encoded string. We should probably just switch the nsPkcs11 code to use UTF8 throughout for module names.
Hardware: x86 → All
Version: unspecified → Trunk
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
Priority: -- → P2
blocking2.0: --- → ?
Flags: wanted1.9.2+
Flags: blocking1.9.2-
Flags: blocking1.9.2+


7 years ago
Assignee: kaie → nobody
Whiteboard: [psm-smartcard]

Comment 4

7 years ago
This is a bug, but it's not serious enough to block Firefox 4 release. I'd still take a patch, though.
blocking2.0: ? → -
status1.9.1: ? → wontfix


7 years ago
Duplicate of this bug: 521296
Created attachment 516846 [details] [diff] [review]


7 years ago
Attachment #516846 - Flags: review?(kaie)


5 years ago
Attachment #516846 - Flags: review?(rrelyea)

Comment 7

5 years ago
Comment on attachment 516846 [details] [diff] [review]

r+ for the conversion to UTF8. All NSS/PKCS #11 calls are defined to be UTF8, so UTF16 values should all be converted.

Someone else should verify that the memory usage and xpcom standards are correct.

Attachment #516846 - Flags: review?(rrelyea) → review+

Comment 8

5 years ago
Comment on attachment 516846 [details] [diff] [review]

Thanks Bob.

r=kaie for the remainder of the patch
Attachment #516846 - Flags: review?(kaie) → review+

Comment 9

5 years ago
Makoto Kato, thank you very much for your contribution!
Target Milestone: --- → mozilla17
Last Resolved: 5 years ago
Resolution: --- → FIXED


2 years ago
Duplicate of this bug: 385805
Duplicate of this bug: 506686
You need to log in before you can comment on or make changes to this bug.