Add-ons/Extension Signing: Difference between revisions

Addons and Extensions are XPI files (zip archives) where each file in the archives is hashed, and the manifest containing all the hashes is signed. When signing an extension, a manifest file containing the hash of each file in the XPI is first generated. The manifest file is stored in the signed XPI under '''META-INF/manifest.mf'''. The snippet below shows an example of manifest file.

A PKCS7 detached signature is computed on "mozilla.sf", using a signing certificate generated for each signature. The signing certificate, also called end-entity cert, is issued by an intermediate certificate of the Firefox private PKI. No special key usage or extended key usage is required in the end-entity cert, but its subject CN must match the addon ID (for example, addon ID test@tests.mozilla.org would have a cert CN set to that value).

Note: If the addon ID is longer than 64 character, we use the SHA256 hash of the addon ID in the end-entity subject CN, to work around issues with long string in certificates (see [https://bugzilla.mozilla.org/show_bug.cgi?id=1203787 bug 1203787]).

When installing addons, Firefox does the following verifications:

=== Signing of special addons ===

There are three special cases of addons developed by Mozilla: System addons, Mozilla Extensions and Hotfixes.

If the addon is a system addon, the Organizational Unit (OU) of the end-entity certificate must be set to "Mozilla Components".

If the addon is a Mozilla Extension, the OU of the EE cert must be set to "Mozilla Extensions".

If the addon is a hotfix, the addon ID must match the pref `extensions.hotfix.id`

For unlisted (non-AMO) add-ons, submission and signing is active through [https://addons.mozilla.org AMO], and there is a [https://blog.mozilla.org/addons/2015/11/20/signing-api-now-available/ Signing API available] for automated submission and retrieval of unlisted addons.

** The [https://www.mozilla.org/firefox/developer/ Developer Edition] and [https://nightly.mozilla.org/ Nightly] versions of Firefox will have a setting to disable signature enforcement. There are also be special [https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds unbranded versions of Release and Beta] that will have this setting (see , so that add-on developers can work on their add-ons without having to sign every build. To disable signature checks, you will need to set the <code>xpinstall.signatures.required</code> preference to "false".

* How will the [[Add-ons/Extension_Signing#Unbranded_Builds|unbranded versions of Firefox]] work?

** They work just like Firefox, with two differences: they will have a setting to disable mandatory signature checks, and they will not have the Firefox name and logo (instead using a generic name and logo). These builds are available in the en-US locale only.

** The ESR release will support signing starting with version 45-based releases. Signing enforcement will be enabled by default in these releases, and enforcement can be disabled using the <code>xpinstall.signatures.required</code> preference.

** For unlisted add-ons, files submitted for signing will go through an automated review process. If they pass this review, they are automatically signed and a download link is sent back to the developer. This process should normally take seconds. If the file doesn't pass review, the developer will have the option to request a manual review, which should take less than two days. This is not the same process that currently applies to AMO add-ons, which has been typically slower.

** No, the purpose of this is to protect users from malicious add-ons. We have [https://developer.mozilla.org/en-US/Add-ons/Add-on_guidelines clear guidelines] for when it is appropriate to blocklist an add-on and have refused multiple times to block for other reasons.