Confirmed users
1,158
edits
EngineeringProductivity/HowTo/SignExtensions: Difference between revisions
EngineeringProductivity/HowTo/SignExtensions (view source)
Revision as of 23:23, 2 June 2017
, 2 June 2017no edit summary
No edit summary |
No edit summary |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
With the new addon signing requirement, working with | '''Update: June 2017''' | ||
In the Add-on manager now checks isInAutomation to see if Firefox is running in the test suite or not. If it is, then the signing checks are bypassed. Meaning that '''most of this document is now no longer relevant'''. All new tests should not need to sign an add-on. There might be some old tests that are still affected. | |||
---- | |||
With the new addon signing requirement, working with addons in mozilla-central gets a little more complicated. Anytime an addon is modified, it will need to be version bumped and re-signed. Yes, even if you just want to add a dump statement to debug a try run. Yuck! This guide is intended to provide all the information you need to work with signed addons in mozilla-central. At first, signing will largely be a manual process, but eventually tooling will improve and the process will get easier. | |||
== Prerequisites == | == Prerequisites == | ||
1. Obtain the [https://mana.mozilla.org/wiki/display/ateam/Signing+Extensions+in+Tree signing keys]. You'll need LDAP to access them. If you do not have LDAP, unfortunately you will not be able to sign | 1. Obtain the [https://mana.mozilla.org/wiki/display/ateam/Signing+Extensions+in+Tree signing keys]. You'll need LDAP to access them. If you do not have LDAP, unfortunately you will not be able to sign addons in mozilla-central. | ||
2. Install jpm by following the [https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/jpm official instructions]. Make sure you have at least version 1.0.5 by running: | 2. Install jpm by following the [https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/jpm official instructions]. Make sure you have at least version 1.0.5 by running: | ||
$ jpm --version | $ jpm --version | ||
== Signing an | Note: jpm is one way to sign add-ons, there is also a [http://addons-server.readthedocs.org/en/latest/topics/api/signing.html REST API interface] for this, it uses the same keys. | ||
You've made changes to an | |||
== Signing an Addon == | |||
You've made changes to an addon, and want to check them into the tree. But automation won't pick your changes up until you've signed it. Here's what you need to do step by step. | |||
1. Bump the version number in install.rdf. It's not possible to sign the same version twice, so each change requires a version bump. If appropriate, you may want to add a new minor version number (e.g x.y.z). | 1. Bump the version number in install.rdf. It's not possible to sign the same version twice, so each change requires a version bump. If appropriate, you may want to add a new minor version number (e.g x.y.z). | ||
2. If your | 2. If your addon is not generated by the build, skip to step 3. Otherwise, you'll first need to build your addon with `mach build`. After building, cd to the final addon directory (usually in $OBJDIR/dist/xpi-stage). | ||
3. Pack the addon into an xpi. An xpi file is simply a renamed zip file. For example, you could use: | 3. Pack the addon into an xpi. An xpi file is simply a renamed zip file. For example, you could use: | ||
| Line 20: | Line 28: | ||
$ jpm sign --api-key <amo key> --api-secret <amo secret> --xpi <path to xpi> | $ jpm sign --api-key <amo key> --api-secret <amo secret> --xpi <path to xpi> | ||
5. If validation failed, open the link to see what needs to be changed. If it was successful, you should have a new .xpi file in your working directory. If appropriate, move and/or rename this file to whatever the relevant automation is expecting. | 5. If validation failed, open the link to see what needs to be changed. If it was successful, you should have a new .xpi file in your working directory. If appropriate, move and/or rename this file to whatever the relevant automation is expecting. If it's not obvious why signing failed, please contact the Add-ons team (usually #amo works). The signing through addons.mozilla.org is a bit stricter about what it accepts than might be needed for mozilla-central. | ||
6. Add the signed | 6. Add the signed addon to your commit: | ||
$ hg add my-addon-signed.xpi | $ hg add my-addon-signed.xpi | ||
$ hg commit -m "Bug 1234567 - Update my-addon.xpi" | $ hg commit -m "Bug 1234567 - Update my-addon.xpi" | ||
| Line 32: | Line 40: | ||
* If you or someone else previously bumped an addon's version number to test changes on try, but never actually committed the changes, then simply incrementing that addon's version number by one won't work. You'll need the last signed version, which is not necessarily the last checked in version. | * If you or someone else previously bumped an addon's version number to test changes on try, but never actually committed the changes, then simply incrementing that addon's version number by one won't work. You'll need the last signed version, which is not necessarily the last checked in version. | ||
* After an addon is signed by one key, it can't later be signed by a second. So it's important to use the shared automation account. | * After an addon is signed by one key, it can't later be signed by a second. So it's important to use the shared automation account. | ||
* Addons with an application id of "toolkit@mozilla.org" don't currently get signed | * If you have accidentally signed an add-on yourself, AMO allows an add-on to be shared by multiple owners. Go to addons.mozilla.org > Tools > Manage My Submissions > [Your add-on] > Manage Authors and add "release+signaddons@mozilla.com" as an owner. | ||
* Addons with an application id of "toolkit@mozilla.org" don't currently [https://github.com/mozilla/addons-server/issues/1740 get signed by design on AMO] and jpm won't warn you of this. To fix this, change the application id to Firefox's uuid. | |||
== How to Avoid Addon Signing == | == How to Avoid Addon Signing == | ||
Signing | Signing addons can potentially be a pretty big pain. But with a bit of effort, that pain can be avoided. | ||
=== Don't use Addons === | === Don't use Addons === | ||
| Line 48: | Line 56: | ||
* They can't be installed via the profile (you'll need to be able to run chrome JS) | * They can't be installed via the profile (you'll need to be able to run chrome JS) | ||
If those restrictions don't bother you, you can use the `[https://dxr.mozilla.org/mozilla-central/rev/d848a5628d801a460a7244cbcdea22d328d8b310/toolkit/mozapps/extensions/AddonManager.jsm# | If those restrictions don't bother you, you can use the `[https://dxr.mozilla.org/mozilla-central/rev/d848a5628d801a460a7244cbcdea22d328d8b310/toolkit/mozapps/extensions/AddonManager.jsm#2236 AddonManager.installTemporaryAddon()]` API to install them. You'll need a way to run chrome privileged JS to install it. Alternatively, there's also a [http://marionette-client.readthedocs.org/en/latest/reference.html#addons marionette API] to install it. For example: | ||
from marionette_driver.addons import Addons | from marionette_driver.addons import Addons | ||
| Line 55: | Line 63: | ||
If this is an option for you, the short term hassle may be worth the long term benefit of not having to sign. | If this is an option for you, the short term hassle may be worth the long term benefit of not having to sign. | ||
=== Tested unsigned addons in unbranded builds === | |||
If need to test unsigned extensions in a build, you can use a build that isn't in either beta or release streams. There are plans to provide unbranded builds for extension providers to use for testing based on beta and release streams, see {{bug|1186522}} | |||