One of the requirements that we came up with in the security review of the hotfix feature was that the hotfix be code signed and Firefox verifies that it was signed by a specific certificate when it downloads it. To do this we need to get an object signing certificate. I'm using similar code to that used by the app update service so if we wanted we could buy two certificates and have Firefox trust them both, I don't know if we can remotely revoke certs for code signing but it might be useful in the case where we want to stop trusting one of the certs from one Firefox version onwards but still have a cert that works in later and previous versions. The security folks probably have better ideas here. I've put a tentative dependency on bug 582347 as we've been trying to get a code signing cert there for a while, but I would guess that maybe we want a different one dedicated to the hotfix stuff. Once we have the certificate I'll need the sha1 fingerprint of it for bug 704988 and we'll probably also want to do some tests.

What kind of certificate is this? Does it need to be from a trusted root, or can we generate our own?

It needs to be from a trusted root. Here are some details: https://developer.mozilla.org/en/Signing_a_XPI#Obtaining_a_valid_software_developer_code-signing_certificate

CC'ing John. Sounds like this is one of the final blockers for trying to land add-on hotfixes in FF10 (see https://wiki.mozilla.org/Features/Desktop/Add-on_hotfix and bug 694068). Is this something that we can target to resolve in the next couple of weeks? Any more info necessary to complete this request or concerns? Thanks!

per channel meeting yesterday, legneato + akeybl will update this bug and bug#582347 with what we are being asked to do, in order to better know what type of keys to get, and where/how to store it. Paraphrasing https://bugzilla.mozilla.org/show_bug.cgi?id=582347#c4 and yesterday's meeting: * what is going to be signed? * who is going to do the signing? how frequently? * what machine will this signing be done on - and how secure does that machine have to be? * will this signing be done *during* of a firefox release? ** if it is a separate unrelated signing/release event: *** does this require "chemspill capability"? *** where/how are these signed addons being distributed to users? Bundled with FF? Hosted on a.m.o? on ftp.m.o? Other? (meanwhile, reassigning to coop who is covering on this for me while I'm out on vacation.)

(In reply to John O'Duinn [:joduinn] from comment #4) > per channel meeting yesterday, legneato + akeybl will update this bug and > bug#582347 with what we are being asked to do, in order to better know what > type of keys to get, and where/how to store it. > > Paraphrasing https://bugzilla.mozilla.org/show_bug.cgi?id=582347#c4 and > yesterday's meeting: > > * what is going to be signed? An XPI, per https://bugzilla.mozilla.org/show_bug.cgi?id=707207#c2 > * who is going to do the signing? how frequently? Presumably RelEng. As many times as we need to release a hotfix, which could be more frequently than chemspills (especially given how much subtler of an approach this is) > * what machine will this signing be done on - and how secure does that > machine have to be? Since this will be occurring within RelEng, I have no preference to the machine. The machine should be no less secure than the machines that we sign binaries with. > * will this signing be done *during* of a firefox release? This does not need to be a part of the build process, but I suspect we may at some point find an issue that requires an add-on hotfix after going to build, in which case we may want to sign at the same time as a build (but not part of the same process). I may be misunderstanding you here though. > ** if it is a separate unrelated signing/release event: it is > *** does this require "chemspill capability"? I'm not sure what you mean by chemspill capability, but we should be able to sign an XPI developed by engineering on short notice, yes. > *** where/how are these signed addons being distributed to users? Bundled > with FF? Hosted on a.m.o? on ftp.m.o? Other? Per conversation with mossop, hosted on AMO.

Note we are not asking for this to be automated at all in the short to medium term. We just want a) a cert and b) some place to store it. If it needs to be on a thumbdrive held by Alex and manually signed by him before the add-on is uploaded to AMO I'd be fine with that as well (though the security team might not be ha ) It is important to get a cert of the correct type ASAP so that we can put the fingerprint in Firefox (requires a trivial patch).

As an update, catlee has been trying to get this working with the existing signing cert today. Progress is ongoing in #release-drivers.

Alex Keybl wrote: > We're currently blocked on RelEng finding out whether the signing > certificate for Firefox binaries is sufficient for use with add-on > hotfix XPIs. I'd like to get a final decision today (John/Chris?) so > that we know whether to uplift 694068 to FF10beta4 in preparation > for testing. This is our last chance to get the hotfix work into > Beta 10. Thanks in advance. AFAICT, An Authenticode certificate is pretty much guaranteed to never work as an XPI signing certificate. From https://developer.mozilla.org/en/Signing_a_XPI: "Currently FireFox expects XPI files to be signed with certificates that conform to the older Object Signing convention, rather than the newer Code Signing convention." IMPORTANT: Ignore the following bit of misinformation on that wiki page: "This means that Firefox will refuse to install code signed via an intermediate certificate authority such as Certum Level I unless the user installs that intermediate CA certificate into Firefox first. Installing the intermediate CA certificate causes Firefox to mark the intermediate Code Signing CA certificate as a valid Object Signing CA certificate, which makes it all work." AFAICT, the above paragraph IS NOT ACCURATE. From https://bugzilla.mozilla.org/show_bug.cgi?id=321156#c1: "[The intermediate certificate must have the] netscape-cert-type extension (bit 7 set) or an EKU extension with the code signing OID (1.3.6.1.5.5.7.3.3)." An authenticode certificate won't have either of these properties, AFAICT. Also, from http://markmail.org/message/v7qmzqky7clgthsd: Dan Veditz wrote on Mar 16, ****2006*** in dev-platform: > Was it a "Netscape code signing" cert? A MS Authenticode > cert will not work. In addition, of course, the root CA must have the code signing trust bit set in our NSS root trust database. (In reply to Dave Townsend (:Mossop) from comment #0) > I don't know if we can remotely revoke certs for code signing but it might > be useful in the case where we want to stop trusting one of the certs from > one Firefox version onwards but still have a cert that works in later and > previous versions. The security folks probably have better ideas here. For now, we should request the certificates from a CA that will honor our request to revoke the certificate (via OCSP) if we are ever to make such a request. But, this would revoke it for all versions of Firefox.

This adds the fingerprint for the release cert that we've been testing

Landed in inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/0af33fc7dbeb

Comment on attachment 587401 [details] [diff] [review] Add cert fingerprint [Approval Request Comment] Testing completed (on m-c, etc.): None Risk to taking this patch (and alternatives if risky): None, either the certificate is correct or it is just as bad as having "foo" there!

Comment on attachment 587401 [details] [diff] [review] Add cert fingerprint [triage comment] Because we're going to test bug 694068 and bug 704988 on beta, this is approved to land there. We also want it on aurora, approved there.

Based on using a pre-existing cert and the patch landing I think we can just call this fixed.

https://hg.mozilla.org/releases/mozilla-beta/rev/e634ee5d7aca https://hg.mozilla.org/releases/mozilla-aurora/rev/bb68dc94aa47