Closed
Bug 1505148
Opened 6 years ago
Closed 6 years ago
Convert extension signing tests away from bootstrap
Categories
(Toolkit :: Add-ons Manager, enhancement, P1)
Tracking
()
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: aswan, Assigned: aswan)
References
Details
Attachments
(3 files)
No description provided.
Assignee | ||
Comment 1•6 years ago
|
||
: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 https://lapo.it/asn1js/ 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.
Assignee | ||
Comment 4•6 years ago
|
||
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 "broken@tests.mozilla.org" (ie, that should be in the CN field)
- long_63.xpi and long_64.xpi signed as described in https://bugzilla.mozilla.org/show_bug.cgi?id=1250611#c26
- 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)
Hi,
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.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486874#c46
[2] https://mana.mozilla.org/wiki/display/FIREFOX/Internal+Extension+Signing
Flags: needinfo?(wezhou)
Assignee | ||
Comment 6•6 years ago
|
||
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 https://addons.mozilla.org/en-US/developers/, 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)
Assignee | ||
Comment 8•6 years ago
|
||
Ben,
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)
Comment 9•6 years ago
|
||
Andrew,
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)
Updated•6 years ago
|
Priority: -- → P1
Comment 10•6 years ago
|
||
I signed ext2.xpi using the `mozillaextension` key.
Flags: needinfo?(rdalal)
Comment 11•6 years ago
|
||
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.
Assignee | ||
Comment 12•6 years ago
|
||
Habib, can you help me find somebody who can manually sign some xpis?
Flags: needinfo?(habib)
Assignee | ||
Comment 13•6 years ago
|
||
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)
Assignee | ||
Comment 14•6 years ago
|
||
Assignee | ||
Comment 15•6 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8f1cde3432cdd1645a91b7943b6054cfadcd6248
Bug 1505148 Switch addon signing tests to webextensions r=kmag
Comment 16•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in
before you can comment on or make changes to this bug.
Description
•