Closed Bug 1505148 Opened 3 years ago Closed 3 years ago

Convert extension signing tests away from bootstrap


(Toolkit :: Add-ons Manager, enhancement, P1)

60 Branch



Tracking Status
firefox65 --- fixed


(Reporter: aswan, Assigned: aswan)




(3 files)

No description provided.
:keeler, when I examine regular signing certificates with "openssl pkcs7 -inform der -in mozilla.rsa -print_certs -text -noout" I see this line:
Signature Algorithm: sha256WithRSAEncryption

In bug 1422904 you added the file toolkit/mozapps/extensions/tests/xpcshell/data/signing_checks/bootstrap_sha256_1.xpi.  The filename and bug both suggest is signed with sha256 but the openssl command above reports:
Signature Algorithm: sha384WithRSAEncryption

I'm about to convert these xpis to webextensions and get them re-signed, should that one just be renamed to sha384?  Or is something else going on here?
Flags: needinfo?(dkeeler)
Assuming you're referring to signed_bootstrap_sha256_1.xpi, it looks like the signing certificate and the certificate that issued the signing certificate were signed with sha384WithRSAEncryption, but the PKCS#7 data itself was signed with sha256WithRSAEncryption (if you open that file with and look at the second-to-last line, it should tell you what the signature algorithm is). I believe that openssl command tells you what the certificates were signed with, which is misleading in this case.
Flags: needinfo?(dkeeler)
Looks like if you use "-print" instead of "-print_certs" it'll work as expected.
Attached file
Thanks for the explanation keeler!

So to make these tests work after we remove bootstrapped extensions we need some special signing of the xpis in the attached zip file:

- ext1.xpi can just be signed normally
- a copy of ext2.xpi signed normally
- a copy of ext2.xpi signed as a privileged extension (ie with "Mozilla Extensions" in the signing certificate OU field)
- a copy of ext2.xpi in which the pkcs7 data is signed with sha256 (see comment 2)
- a copy of ext2.xpi signed as if its id was "" (ie, that should be in the CN field)
- long_63.xpi and long_64.xpi signed as described in
- long_65.xpi signed with the hashed id

wezhou, can you handle these requests?  if not, can you redirect me to somebody who can?
Flags: needinfo?(wezhou)

I can help you sign what's known as "system addons". One example of this type addons is the one I signed in [1]. Please let me know if that's the type you want me to help with in this ticket, and I'll sign it accordingly.

For signing "internal addons", please take a look at this page [2], and request some one listed in the "Team Access" table on that page to help sign it for you.

Flags: needinfo?(wezhou)
These extensions should be signed as regular (neither system nor internal) addons, with all the twists described in comment 4 that are not doable from any public APIs.  If you don't have the ability to do that type of signing, can you point me to somebody who can?
Flags: needinfo?(wezhou)
The only other type of addons I'm aware of is the user addons. Usually what happens with that type of addons is that you go to, register an account and sign in, then you'll be able to submit an addon. The addon will get signed automatically if it passes the auto-validation process of the site.
Flags: needinfo?(wezhou)
The addons attached here need to be signed as user addons but with some special treatment as described in comment 4.  Can you help me figure out who can actually do the signing?
Flags: needinfo?(bwong)

I don't think we have all the keys/access in order to accomplish what's required in Comment #4.  Maybe :ulfr and :rehan can weigh in on this one.
Flags: needinfo?(rdalal)
Flags: needinfo?(jvehent)
Flags: needinfo?(bwong)
Priority: -- → P1
I signed ext2.xpi using the `mozillaextension` key.
Flags: needinfo?(rdalal)
So ulfr is on PTO.  I think the only people with access to the key material you need for comment #4 would be the ops team.
Habib, can you help me find somebody who can manually sign some xpis?
Flags: needinfo?(habib)
Never mind, I think that with the privileged signature and the public AMO API I can rewrite most of the tests we care about.  This will entail dropping some tests that cover how the browser handles signatures that we shouldn't be generating in the first place (eg mismatched id, improperly hashed long ids, etc.) but I don't think we're getting much value from those tests.
Flags: needinfo?(jvehent)
Flags: needinfo?(habib)
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.