Closed Bug 495756 Opened 11 years ago Closed 11 years ago

Documentation NEEDED for installing PKCS11 modules, now that pkcs11.addmodule() is disabled

Categories

(Developer Documentation :: General, defect, blocker)

x86
All
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sander, Unassigned)

References

Details

(Keywords: dev-doc-complete, relnote)

Copy from bug #326628 comments:

Where is the documentation for a workaround?!? This came as a VERY BAD news for
us. In Europe Estonia is not the only country using ID-cards. And removing this
functionality without any info about workaround is a very-very bad practice!

https://ideelabor.ee/opensource/wiki/IdKaardiTarkvara/VeebisAutentimineMozillaga
- this page is usless for Firefox 3.5. How can we do the same thing with xpi?

Dumbuser can't find even device manager.. How should they find correct module
to load?!

I'm really waiting for GOOD documentation as this is a release blocker for
Estonia and other countries using smart cards.
Flags: blocking-firefox3.5?
We should absolutely document this change, since sites which relied on the previous API will need to understand what's changed.  Copying some people.

Here's the short story:

 - Bug 326628 removed an old javascript API because it had some disconcerting security properties.
 - The API let web pages add/remove crypto modules - this means they can tell Firefox to add certs from a smart cards to support authentication, but also that they can tell Firefox to add new trusted CAs, and potentially execute some unsavoury attacks.
 - These exploits required the user to already have the malicious file on their local system - it's not a total compromise or anything, but it's also more dangerous than is really warranted.
 - The argument (see bug 326628 comment 29) is that legitimate providers of these tokens can put together a simple XPI to do the work, instead of using a content-exposed API. Presumably they already have sufficient user trust to get files onto their users'/customers', so the XPI install process shouldn't be a significant barrier.

This means that we need to document that process, though.

This is mostly a dev-doc issue, but I'm copying dtenser as well, in case he wants to put together a user support doc to anticipate potentially confused users of sites that don't update themselves.

The code to add/delete modules from an XPI is pretty straightforward and can likely be copied from 

http://mxr.mozilla.org/mozilla-central/source/security/manager/pki/resources/content/device_manager.js

but I'd like bsmedberg or kaie to comment on the details, since I know it took a couple tries to get this right.

I think this should be relnoted for the release, and that relnote should point to documentation.  It's hard for me to gauge the scope of the impact here, and hence hard for me to make a blocking recommendation.  I would certainly feel better if it were documented before we shipped it and sites started getting surprised.
Assignee: nobody → kaie
Component: General → Security: PSM
Flags: blocking-firefox3.5?
Product: Firefox → Core
QA Contact: general → psm
Target Milestone: Firefox 3.5 → ---
Version: 3.5 Branch → unspecified
Restoring blocking nom after component move - this is really a docs bug, but a docs bug against PSM changes, so this felt like a better place for it to live, for now.
Flags: blocking1.9.1?
Blocks: 326628
It would be helpful if someone familiar with this issue could either write this article, or contribute extensive notes that I could turn into an article, since I don't really know what's going on here.
--> MDC as this won't be a code-related blocker.
Assignee: kaie → nobody
Component: Security: PSM → Documentation Requests
Flags: blocking1.9.1?
Product: Core → Mozilla Developer Center
QA Contact: psm → doc-request
Johnath/Smedberg: can you help with comment 3?
The user-interface part of that doc probably ought to live on support.mozilla.com and not here, but I'm not sure how SUMO works.
Summary: Documentation NEEDED for workaround of bug #326628 → Documentation NEEDED for installing PKCS11 modules, now that pkcs11.addmodule() is disabled
The original design intent of the facilities for adding new PKCS#11 modules
to the mozilla browser was to offer two separate methods:
1) a UI dialog in the security manager preferences, 
2) a javascript method invokable from an XPI installer.  

https://developer.mozilla.org/en/PKCS11_Module_Installation provides minimal
information about both methods.

We expected that most PKCS#11 modules would be installed via an XPI.  

Somehow, somewhere along the way, it became possible to invoke the javascript 
method from a web page, and developers of deployments of PKCS#11 modules
began to rely on that.  But that was vulnerable, and now that has been taken 
away, leaving developers wondering what to do instead. 

IMO, the right thing to do is to steer those developers back to developing 
XPIs, rather than trying to teach users how to find and use the UI for this 
installation.  We really should encourage developers to consider the XPI
as the primary vehicle for that installation, IMO.
"XPIs" no longer have install scripts (install.js)... they are Firefox addons. So the correct answer for installing a PKCS11 module would be to have an extension do something like this:

var pkcs11 = Components.classes["@mozilla.org/security/pkcs11;1"].getService(Components.interfaces.nsIPKCS11);
pkcs11.addModule('name', path, cryptoflags, cipherflags);
Component: Documentation Requests → Documentation
Component: Documentation → General
Product: Mozilla Developer Network → Developer Documentation
You need to log in before you can comment on or make changes to this bug.