[dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on dev-platform]
Hello Everyone, You may or may not be surprised to learn that Gecko contains two different ways to verify that an add-on has been signed. The primary method is nsIX509CertDB.openSignedAppFileAsync. This is what Gecko-based products that require add-on signing use. However, there is also nsIZipRreader.getSigningCert (plus some additional glue code). The only place where these two implementations share code is in the actual signature verification. That is, the logic to ensure that every file in the archive has a corresponding valid entry in the manifest (and that every entry in the manifest has a corresponding file in the archive) and so on appears in Gecko twice. From what I can tell, the actual functionality provided by the second API (which is only applicable in builds that do not require add-on signing) is a small text label in the install dialog that identifies the certificate that signed the add-on. Note that this isn't even the dialog that Firefox uses by default - you have to flip "xpinstall.customConfirmationUI" to false to see it. In the default dialog in Firefox, there is no difference between an unsigned add-on and an add-on signed by a non-Mozilla root certificate that has been trusted for code signing (and note that soon no certificate in Mozilla's root CA program will have the code signing trust bit enabled by default [0]) (and again, this only applies to builds where add-on signing isn't required - for builds where it is required, this API is not used at all). Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey use it for any reason, or can we simplify the code-base, reduce build size, etc.? Cheers, David [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1366243
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
