"Load PKCS#11 Device" dialog doesn't work (pkcs11.addmodule call fails)

RESOLVED FIXED

Status

()

defect
--
major
RESOLVED FIXED
10 years ago
2 months ago

People

(Reporter: gchudov, Assigned: benjamin)

Tracking

({verified1.9.1})

Trunk
Points:
---
Bug Flags:
blocking1.9.1 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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

10 years ago
Severity: normal → major
Version: unspecified → Trunk
(Assignee)

Comment 1

10 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?
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

10 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.
(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

10 years ago
shaver suggests backing out bug 326628 completely.

Updated

10 years ago
Blocks: 326628

Comment 6

10 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

10 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)
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.

Updated

10 years ago
Attachment #379724 - Flags: review?(rrelyea)
Attachment #379724 - Flags: review?(kaie)
Attachment #379724 - Flags: review-
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.
(Assignee)

Comment 14

10 years ago
Fixed on -central and -1.9.1 by backing out bug 326628
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-litmus?
Keywords: fixed1.9.1
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
Posted file test instructions
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ago10 years ago
Resolution: --- → FIXED

Comment 28

10 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.
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.