Closed
Bug 494899
Opened 15 years ago
Closed 15 years ago
"Load PKCS#11 Device" dialog doesn't work (pkcs11.addmodule call fails)
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: gchudov, Assigned: benjamin)
References
Details
(Keywords: verified1.9.1)
Attachments
(2 files, 1 obsolete file)
5.65 KB,
patch
|
KaiE
:
review-
|
Details | Diff | Splinter Review |
3.16 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.0.3) Gecko/2008092417 (SV1; Alexa Toolbar; MEGAUPLOAD 1.0) Firefox/3.0.3 Build Identifier: Gecko/20090525 Minefield/3.6alpre The "Load PKCS#11 Device" dialog (Minefield Preferences->Advanced->Encryption->Security Devices->Load) doesn't work: 'Ok' button doesn't do anything. The corresponding code is in mozilla-central\security\manager\pki\resources\content\device_manager.js: function doLoadDevice() { var name_box = document.getElementById("device_name"); var path_box = document.getElementById("device_path"); pkcs11.addmodule(name_box.value, path_box.value, 0,0); return true; } As pkcs11 object has been removed, this dialog no longer works. This is supposed to have something to do with bug 326628. Reproducible: Always Steps to Reproduce: 1.Go to Minefield Preferences->Advanced->Encryption->Security Devices->Load 2.Select any pkcs11 module or just any shared library 3.Press ok Actual Results: JavaScript error: chrome://pippki/content/device_manager.js, line 463: pkcs11 is not defined Expected Results: There should be an attempt to load the module.
Reporter | ||
Updated•15 years ago
|
Severity: normal → major
Version: unspecified → Trunk
Assignee | ||
Comment 1•15 years ago
|
||
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
Flags: blocking1.9.1?
Comment 2•15 years ago
|
||
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?
Assignee | ||
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
(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
Assignee | ||
Comment 5•15 years ago
|
||
shaver suggests backing out bug 326628 completely.
Comment 6•15 years ago
|
||
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.
Assignee | ||
Comment 7•15 years ago
|
||
This fixes the dialog: we alert for install failures and confirm module deletions using strings which are already present in 1.9.1
Attachment #379724 -
Flags: review?(kaie)
Attachment #379724 -
Flags: review?(johnath)
Updated•15 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Comment 8•15 years ago
|
||
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)
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
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.
Comment 11•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #379724 -
Flags: review?(rrelyea)
Attachment #379724 -
Flags: review?(kaie)
Attachment #379724 -
Flags: review-
Comment 12•15 years ago
|
||
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.
Comment 13•15 years ago
|
||
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.
Assignee | ||
Comment 14•15 years ago
|
||
Fixed on -central and -1.9.1 by backing out bug 326628
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-litmus?
Keywords: fixed1.9.1
Resolution: --- → FIXED
Comment 15•15 years ago
|
||
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 16•15 years ago
|
||
Comment 17•15 years ago
|
||
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
Comment 18•15 years ago
|
||
Hopefully the images will be visible in these instructions.
Comment 19•15 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
Comment 20•15 years ago
|
||
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.
Comment 21•15 years ago
|
||
https://litmus.mozilla.org/show_test.cgi?id=7756 added to Litmus.
Flags: in-litmus? → in-litmus+
Comment 22•15 years ago
|
||
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?
Comment 23•15 years ago
|
||
Also, I'm not able to verify this on the nightly build on Mac, as I can't specify a module to load successfully.
Updated•15 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 24•15 years ago
|
||
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.
Comment 25•15 years ago
|
||
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.
Comment 26•15 years ago
|
||
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.
Comment 27•15 years ago
|
||
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
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Comment 28•15 years ago
|
||
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.
Updated•11 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•