Closed Bug 1505148 Opened 11 months ago Closed 10 months ago
Convert extension signing tests away from bootstrap
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?
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.
Looks like if you use "-print" instead of "-print_certs" it'll work as expected.
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 "email@example.com" (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?
Hi, I can help you sign what's known as "system addons". One example of this type addons is the one I signed in . 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 , and request some one listed in the "Team Access" table on that page to help sign it for you.  https://bugzilla.mozilla.org/show_bug.cgi?id=1486874#c46  https://mana.mozilla.org/wiki/display/FIREFOX/Internal+Extension+Signing
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?
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.
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?
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.
I signed ext2.xpi using the `mozillaextension` key.
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?
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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/8f1cde3432cdd1645a91b7943b6054cfadcd6248 Bug 1505148 Switch addon signing tests to webextensions r=kmag
You need to log in before you can comment on or make changes to this bug.