AMO/SigningService: Difference between revisions

(→‎Schedule of Signing Rollout: schedule crrection)
 
(31 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{draft}}
= Add-on Signature System =
= Add-on Signature System =


Hi.  This project is the AMO piece of the larger [https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit Add-on Signature System].  Please read that document so the rest of this wiki page makes sense.
Hi.  This project is the AMO piece of the larger [https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit 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 [https://wiki.mozilla.org/AMO/SigningService/Meetings 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:
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:
Line 16: Line 19:
* Should not need any API changes since this is all after add-on review
* 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
* 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 ==
== 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===
=== Phase 1: Signing with Trunion===
Line 23: Line 37:
|-
|-
! Current Status
! Current Status
| <span style="color:red; font-weight:bold">Needs Bugs Filed</span>
| <span style="color:green; font-weight:bold">Done</span>
|-
|-
! Owners
! Owners
| Ryan Tilder, Wil Clouser
| Ryan Tilder
|}
|}


Line 51: Line 65:
* Modifying Trunion to send meta-data about what it signed (at least the certificate serial number)
* Modifying Trunion to send meta-data about what it signed (at least the certificate serial number)
* Modifying Trunion to generate certs on-the-fly
* Modifying Trunion to generate certs on-the-fly
[[AMO/SigningService/API|See API Documentation]]


Open Bugs:
Open Bugs:
Line 56: Line 72:
{
{
     "blocks": "1070152",
     "blocks": "1070152",
     "include_fields": "id, priority, status, summary"
     "include_fields": "id, priority, status, summary",
    "status": ["UNCONFIRMED", "ASSIGNED", "NEW", "REOPENED"]
}
}
</bugzilla>
</bugzilla>
Line 64: Line 81:
|-
|-
! Current Status
! Current Status
| <span style="color:red; font-weight:bold">Needs Review</span>
| <span style="color:green; font-weight:bold">Closing bugs!</span>
|}
|}


This will implement the initial AMO support, signing apps after being approved by reviewers.
This will implement the initial AMO support, signing apps after being approved by reviewers. [[AMO/SigningService/API|Trunion API Documentation]]


Open Questions:
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.
* 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: {{Bugzilla|1070153}}


Open Bugs:
Open Bugs:
Line 76: Line 95:
{
{
     "blocks": "1070153",
     "blocks": "1070153",
     "include_fields": "id, priority, status, summary"
     "include_fields": "id, priority, status, summary",
    "status": ["UNCONFIRMED", "ASSIGNED", "NEW", "REOPENED"]
}
}
</bugzilla>
</bugzilla>
Line 85: Line 105:
|-
|-
! Current Status
! Current Status
| <span style="color:red; font-weight:bold">On Hold</span>
| <span style="color:green; font-weight:bold">Wontfixed</span>
|}
|}


'''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.
'''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:'''
'''Summary:'''
Line 104: Line 124:
{
{
     "blocks": "1070154",
     "blocks": "1070154",
     "include_fields": "id, priority, status, summary"
     "include_fields": "id, priority, status, resolution, summary",
    "status": ["UNCONFIRMED", "ASSIGNED", "NEW", "REOPENED"]
}
}
</bugzilla>
</bugzilla>
Line 113: Line 134:
|-
|-
! Current Status
! Current Status
| <span style="color:red; font-weight:bold">TBD</span>
| <span style="color:green; font-weight:bold">Closing bugs</span>
|}
|}


Summary:
Notes:
* This needs payments from Marketplace
* The bugs were inspired by https://etherpad.mozilla.org/jUwP07PtYD
* This needs UX
 
Open Bugs:
<bugzilla>
{
    "blocks": "1122114",
    "include_fields": "id, priority, status, summary",
    "status": ["UNCONFIRMED", "ASSIGNED", "NEW", "REOPENED"]
}
</bugzilla>
 
=== Phase 5: Code Deployment ===
 
{|
|-
! Current Status
| <span style="color:green; font-weight:bold">Donesies</span>
|}
 
Open Bugs (note private bugs won't show up here):
<bugzilla>
{
    "blocks": "1130124",
    "include_fields": "id, priority, status, summary",
    "status": ["UNCONFIRMED", "ASSIGNED", "NEW", "REOPENED"]
}
</bugzilla>
 
== 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.
Confirmed users
613

edits