Severity: normal → major
Version: unspecified → Trunk
I'm not sure this should block, but it sure does suck! I think I can whip together a patch for this. There are two UI options: 1) simple: don't pose any dialogs. After clicking "OK" in the "Load PKCS#11 Device" dialog, the device will be loaded immediately. In previous versions there would be an additional confirmation prompt. Also, the "Unload" button in the Device Manager will take effect immediately without an additional prompt. 2) more complex: re-use the strings for the PKCS11 prompts which I removed in bug 326628 (on -central... the strings are still present on -1.9.1) and pose some or all of the dialogs which would have been posed by the old code.
Assignee: nobody → benjamin
Do I understand correctly that without a fix, people can't load any PKCS#11 devices? If so, that feels like it should block, to me. As for the two options - what do those confirmation dialogs say? Do they ask follow-up questions? Is there a Bad Consequence to not showing them?
http://hg.mozilla.org/mozilla-central/rev/1aaacee9b2d0 are the dialog strings that were no longer needed. The "are you sure you want to install" dialog is IMO unecessary. It's the "are you sure you want to remove" dialog which seems more important.
(In reply to comment #3) > http://hg.mozilla.org/mozilla-central/rev/1aaacee9b2d0 are the dialog strings > that were no longer needed. The "are you sure you want to install" dialog is > IMO unecessary. It's the "are you sure you want to remove" dialog which seems > more important. I think I agree on both points. Can you work up a patch that does that while we try to get some help from the NSS/PSM guys on understanding how to test PKCS#11 module addition/deletion? Adding some CCs, marking confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
shaver suggests backing out bug 326628 completely.
That was a security fix affecting content, while this bug involves only chrome. It should be possible to fix this bug without reintroducing the security hole.
This fixes the dialog: we alert for install failures and confirm module deletions using strings which are already present in 1.9.1
Flags: blocking1.9.1? → blocking1.9.1+
Comment on attachment 379724 [details] [diff] [review] Fix the device manager, rev. 1 Bob or Kai should review this, not me. Adding Bob as well just to expedite, since this is one of a very small set of bugs blocking Firefox 3.5.
Attachment #379724 - Flags: review?(johnath) → review?(rrelyea)
So when we did bug 326628, we didn't check at all whether the removed API is used by ourselves and broke it completely. Wow. This wouldn't have happened with compile time API checking :-( I'm in favor of backing out the patch from bug 326628, but I will try to review the new patch now.
Regarding testing: You need a dynamic library that implements the pkcs#11 interface. If you're on a Linux (Fedora or RHEL) system, you should be able to find file /usr/lib/libcoolkeypk11.so Try to add/load this module, and you should get a new entry in your list of devices. And you should be able to remove it afterwards.
So we learned, the code that has been removed was used by our internal device management UI, too. The new patch proposed here only has 3 information messages, while the old code provided a bigger diversity of messages which assist in diagnosis. For example, you're now missing 12 -AddModuleDup=Security Module already exists 13 -DelModuleBadName=Invalid module name. Also the following two messages are gone: 16 -DelModuleIntSuccess=Internal security module successfully deleted 17 -DelModuleExtSuccess=External security module successfully deleted I can't say out of my head why one would need to know the difference between these two, but there must have been a reason at the time they were introduced. Given that we learned that we broke old behavior, we shouldn't attempt a last minute fix that is incomplete. Time seems to limited to find out for sure that this won't cause other problem. Either we back out the patch, or we do a new patch that is as close to old functionality as possible, without making last minute ad hoc decisions about which functionality seems needed and which does not.
Firefox and TBird absolutely need a way to add and remove PKCS#11 modules. It may not be necessary to allow ordinary web pages to do it, but it is absolutely necessary to allow chrome to do it. Firefox needs test cases for adding and removing PKCS#11 modules, and verifying that they have been added and removed. There are plenty of suitable modules around that can be used for this purpose.
Firefox and TBird need test cases to test their ability to switch into and out of "FIPS mode". That ability relies on the functionality of deleting and adding the "internal" PKCS#11 module, which (I gather) is now absent. This will be a complete show stopper for any US Government users.
Fixed on -central and -1.9.1 by backing out bug 326628
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Nelson: I added one basic test for FIPS in Litmus - https://litmus.mozilla.org/show_test.cgi?id=6820. We should probably add a few more here. (In reply to comment #13) > Firefox and TBird need test cases to test their ability to switch into and > out of "FIPS mode". That ability relies on the functionality of deleting > and adding the "internal" PKCS#11 module, which (I gather) is now absent. > This will be a complete show stopper for any US Government users.
Comment on attachment 379913 [details] How to manually test this bug The images in that email message do not display when viewed in the browser. I'll have to publish this another way.
Attachment #379913 - Attachment is obsolete: true
Hopefully the images will be visible in these instructions.
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre and following Nelson's excellent instructions in Comment 18 which soon will become a Litmus test in the security area. Also verified using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre
Also verified on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre In an earlier version you cannot "Unload" the module; in the latest version you can. Again, thanks for the instructions Nelson.
https://litmus.mozilla.org/show_test.cgi?id=7756 added to Litmus.
Flags: in-litmus? → in-litmus+
Nelson, why would this be locale dependent? Say, when I try the instructions in the fr or es-es locales, the unloading/loading of the module does not work?
Also, I'm not able to verify this on the nightly build on Mac, as I can't specify a module to load successfully.
Juan, I'm not the developer of this code. I don't know of any reason why the behavior would be locale dependent. Maybe it's a bug. It would be useful ot know if that is an old problem, or a recent regression due to the recent changes. I don't know where (in what folder) the files are put on a Mac. I suggest you do a file search for all files with the letters nssckbi in them, and follow the instructions in attachment 380196 [details] for that file, where ever you find it.
Thanks Nelson. I found out why it would not work on Mac. You can't browse for the file by clicking on the button; but you can specify it, just by the file name, if it is at the level of the application binary. I'm going to investigate the locales problem.
It turns out I can see the same behavior in the 3.0.12pre and Fx3.1b3 (fr), for instance. When you try to unload/unload a module, you get a message similar to: "It's not possible to unload the module." This has been around for quite a while. Leaving it re-opened so someone can assess how important this is.
Changing status back to resolved-fixed per conversation in today's platform meeting. I will open a new bug for the issue related to mac, and locales.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → FIXED
From an XPI using a call of the form below doesn't work: var pkcs11 = Components.classes["@mozilla.org/security/pkcs11;1"].getService(Components.interfaces.nsIPKCS11); pkcs11.addModule('name', path, 0, 0); There is no dialog or anything, it just seems to skip this function. Nothing is loaded into the device manager. Nothing shows in the error console. Using Firefox 3.5.3. The call works fine in all of Firefox 3.0.x. Request reopening this bug.
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.