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.?
I looked at the code and don't see any use outside of toolkit. Same for
the PREF_CUSTOM_CONFIRMATION_UI/"xpinstall.customConfirmationUI" pref.
Seems to be only used in browser.
FRG
Frank-Rainer Grahl wrote:
SeaMonkey does not use signing and does not plan to do so. It is
disabled in the mozconfigs during build time in all trees with:
> # Disable checking that add-ons are signed by the trusted root
> MOZ_ADDON_SIGNING=0
> # Disable enforcing that add-ons are signed by the trusted root
> MOZ_REQUIRE_SIGNING=0
So I think we don't have a problem here if something gets changed and
the toolkit code still honors these.
As far as I know Thunderbird does the same.
FRG
David Keeler wrote:
[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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
