mozilla-services / addon-shipping Goto Github PK

The current system addon process is too big and not strictly defined enough to fully automate it. Reasons:

• code lives in hg.mozilla.org and/or github
• sightly different guidance/requirements for the size of the system addon
  • flag flips don't require Intent to Ship tracking bugs
  • One off addons live in the GH repo mozilla/one-ff-system-addons
  • larger, more complex ones can have their own repo and a very extensive tracking bug (example1, example2, example3)
• Lots of discussion, approvals and back and forth discussions. We don't want to build a comment systems

Instead I propose we focus on improving a small part: XPI signing. The current process is for somebody from ops with SSH access to take the XPI, sign it on the right box, and attach it to the tracking bug.

Proposed state machine: (changelog below)

1. Web UI for submitting an XPI
2. Notify verifiers that there's work to do
3. Web UI for secondary approval for signing
4. Background worker submit to autograph for signing (issue #5)
5. Uploader that puts XPI onto ftp.mozilla.org (ref Bug 1281578)
6. Submitter is notified that XPI is ready

This is good because:

• Improve security/bus factor that only people with SSH access to the signing system can sign (ref)
• Remove need to attach XPI to the tracking bug, a public web URL will suffice
• Gives us experience working with Step Functions, Lambda, etc and lets us know if we can scale up this dev process

What we're intentionally not doing:

• The intent/dev/review/qa workflow for a system addon. Bugzilla seems fine.
• Publishing addon to balrog in the test channel: release-sysaddon

changelog (most recent first)

• change "Uploader that puts XPI into into a public S3 bucket" to " Uploader that puts XPI onto ftp.mozilla.org"
• change "Web UI for verifying XPI" to "Web UI for secondary approval for signing"
• link to issue #5 for autograph signing
• added the change log

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

When a new commit merges into master it should be auto built / tested and deployed to the development IAM by CircleCI.

Create a reusable lambda function that can take an XPI and pass it off to the Autograph service to be signed.

We want to create this as a lambda function so it can be reusable in other state machines. We should consider this to be a "high security" component since it needs to hold Hawk credentials for talking with Autograph.

Input:

• Location of XPI file
• SHA256 of expected XPI file
• Auth credentials to generate a Hawk token

Output:

• Location of signed XPI file
• SHA256 of signed XPI file

Algorithm:

1. fetches the XPI file
2. verifies against SHA256 in step fn context
3. generates a manifest for signing
4. sends manifest to Autograph for signing (with Hawk creds)
5. adds signature to new XPI file
6. adds sha256(new xpi) to Step fn context
7. uploads new XPI file to S3

Any failures should:

• exit with a non 0 response code
• log a message to stdout of the problem

Ref: #2 (comment)