Add-on Signature System

Hi. This project is the AMO piece of the larger Add-on Signature System. Please read that document so the rest of this wiki page makes sense.

Meetings

• the Add-On Signing Team meets Fridays at 16:00 UTC (9am Pacific). Meeting minutes are archived here

Signing Architecture

We will need to modify several pieces of AMO and its libraries in order to accommodate this new system. Those changes are roughly laid out below and divided up into phases. See the diagram below (which compares to Marketplace for a reference) for a high level view:

Notes:

• The flows are very similar. Apps load a certificate from disk and get signed. For add-ons we'll load a certificate from disk, but we'll generate a new certificate as well, use the loaded certificate to sign the new certificate, and then sign the add-on with the new certificate.
• When we're done signing we discard the new certificate.
• Any pre-existing signatures on the add-on are replaced. This includes developers who have signed the add-on with a valid AMO certificate already. The expected flow for self-hosting in addition to AMO hosting is to download the signed add-on from AMO, not do any manual signing.
• We don't do any signing before the add-on is approved for the public. Reviewers are expected to use developer versions or debug versions of Firefox so won't need to have the add-ons signed to test them.
• Should not need any API changes since this is all after add-on review
• We're looking at high 10s to low 100s of signed packages per day
• There are three users we're targeting:
  • One: Regular Jane. She writes add-ons and distributes them via AMO. This is the vast majority of developers and their workflow should be largely unchanged (assuming they already develop add-ons with a non-release version of Fx).
  • Two: Particular Joe. He writes add-ons, and is happy to show the code to Mozilla but prefers not to distribute the add-on on AMO. We'll modify AMO to allow him to upload the add-on as usual, but not show the add-on on any public pages.
  • Three: Unusual Quinn. He writes add-ons but refuses to show the code to Mozilla (eg. he may be under an NDA or similar). Hopefully this is a very rare case and a process is still being documented. (Expect something close to: file a security bug, explain circumstances, enter into a legally binding contract with Mozilla, be issued a signing key that you are responsible to keep safe, sign your own add-on)

Roadmap

Schedule of Signing Rollout

(updated September 15, 2015)

• Firefox 40-42: Firefox warns about signatures but doesn't enforce them.
• Firefox 43: Firefox will have a preference that allows signature enforcement to be disabled (xpinstall.signatures.required in about:config).
• Firefox 44: Release and Beta versions of Firefox will not allow unsigned extensions to be installed, with no override.

Phase 1: Signing with Trunion

Summary:

We currently don't sign add-ons at all on AMO, but we do sign apps on the Marketplace using trunion and could use the same system (with modifications). A rough summary of the Trunion overview is as follows:

 1. This CA will be entirely automated and self contained
     1. The CA's root certificate will be hard coded into Firefox/Fennec
        in a similar manner to the privileged FxOS apps
     2. For every request to sign an addon:
          o a brand new 2048 bit or stronger RSA key pair will be
            generated by the signing service
          o the ephemeral public key will be certified by this CA
          o the ephemeral private key generated will then be used to
            sign the addon archive in Mozilla's own bastardized
            implementation of JAR signing that we know as "XPI signing"
          o the freshly certified ephemeral public key will be included
            in the addon as part of the signature chain
          o the ephemeral private key and certificate are thrown away

In practical terms, this means:

• Modifying Trunion to accept meta-data about what it is signing (at least an add-on ID)
• Modifying Trunion to send meta-data about what it signed (at least the certificate serial number)
• Modifying Trunion to generate certs on-the-fly

See API Documentation

Open Bugs:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Phase 2: Initial AMO Support

This will implement the initial AMO support, signing apps after being approved by reviewers. Trunion API Documentation

Open Questions:

• How do we push updates to all existing add-ons after they are signed? Updating to a new version number may be necessary. ([andym] is this still a valid question, or has it been answered?)

Tracking bug: 1070153

Open Bugs:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Phase 3: Blocklist

On Hold: On hold pending further info. Since add-ons are signed and can't change their IDs, and we can already block on IDs this is of questionable value. This would be a blocker if we give partners their own keys to sign their add-ons.

Summary: This system expects to use the blocklist until a more official cert revocation system can be implemented. Blocklist administration will use the administrative scaffolding it currently uses. A new top level item will be added called <certificates>. An example entry is below:

 <certificates>
   <certificate blockID="100">
     <issuer>mozilla.com</issuer>
     <serialnumber>00245EADBDE07F113DEE</serialnumber>
   </certificate>
 </certificates>

Open Bugs:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Phase 4: Non-AMO hosted add-ons

Notes:

• The bugs were inspired by https://etherpad.mozilla.org/jUwP07PtYD

Open Bugs:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Phase 5: Code Deployment

Open Bugs (note private bugs won't show up here):

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Usage

There's two management commands to manually sign add-ons:

sign_addons

This can be used to sign a list of add-ons, by providing their IDs:

python manage.py sign_addons 123 124 125

process_addons

This is a more general management command that can run tasks on every add-on:

python manage.py process_addons --task sign_addons

Running this will sign each add-on. Celery tasks will be used.