mozilla / sign-addon Goto Github PK
View Code? Open in Web Editor NEWSign a Firefox add-on with Mozilla's web service
License: Mozilla Public License 2.0
Sign a Firefox add-on with Mozilla's web service
License: Mozilla Public License 2.0
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:
If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].
(Message COC001)
FYI: The following changes were made to this repository's wiki:
defacing spam has been removed
Restricting write access to contributors is strongly encouraged. Please make that change (documentation).
These were made as the result of a recent automated defacement of publically writeable wikis.
We should release a new version of this lib. Given all the recent changes, it will likely be a new major version. Here is the current changelog:
77dc385 refactor: rewrite test suite with Jest (#364)
01fc2b3 chore: rename test files (#362)
c504b95 refactor: wait for validation & signing separately (#323)
940b77d Setup codecov (#354)
82b6789 Move noEmit into tsconfig (#355)
54c26bd refactor: Move mock classes to tests/helpers.js (#347)
ea9e747 Update README (#341)
82ad42b feat: drop node 8 support, start adding async/await, split source files (#342)
98c185a feat: Add types to one test file (#336)
...and a bunch of dependency updates.
NekR@MacBook:~/...$ gulp ...
Error: Cannot find module 'any-promise'
at Function.Module._resolveFilename (module.js:337:15)
at Function.Module._load (module.js:287:25)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/.../node_modules/sign-addon/dist/sign-addon.js:227:19)
at __webpack_require__ (/.../node_modules/sign-addon/dist/sign-addon.js:22:30)
at Object.<anonymous> (/.../node_modules/sign-addon/dist/sign-addon.js:163:16)
at __webpack_require__ (/.../node_modules/sign-addon/dist/sign-addon.js:22:30)
at Object.<anonymous> (/.../node_modules/sign-addon/dist/sign-addon.js:57:12)
at __webpack_require__ (/.../node_modules/sign-addon/dist/sign-addon.js:22:30)
Signed files will be saved to the current working directory. There should be an option to configure this destination.
The sign function can sometimes download an XPI file which has the contents of {"detail": "Not found"}
. This issue has more details: mozilla-jetpack/jpm#515
Until AMO is fixed I think the steps to reproduce it are:
signAddon()
on an XPIsignAddon()
on the XPI againThe progress indicator needs a new line added after it. It is not apparent because the progress indicator tries to fill the width of the terminal. Here's an example where a new line should be added:
Validating add-on [.................................................................................................]JPM [info] Validation results: https://addons.mozilla.org/en-US/developers/upload/bbdf9073931446968f453b8d415434e5
Downloading signed files: 100%
The current code calls one method which calls another method and so on. This makes it impossible to look in one place and see the complete chain of events necessary for signing an add-on.
After converting to async / await (#324), it would be very helpful to introduce a central controller that calls all other methods sequentially. This would let you look in one place to see the full chain of events.
Here is a rough sketch of how it might look, using Client.sign()
as a controller:
diff --git a/src/amo-client.js b/src/amo-client.js
index b135630..23de9ca 100644
--- a/src/amo-client.js
+++ b/src/amo-client.js
@@ -110,6 +110,13 @@ export class Client {
const doRequest = this[method].bind(this);
+ const [response, responseData] = await doRequest(
+ { url: addonUrl },
+ formData
+ );
+ const data = await this.waitForSignedAddon(responseData.url)
+ const allFiles = await this.downloadSignedFiles(data.files);
+
return doRequest({
url: addonUrl, formData,
}, {
This patch was made against 51d2650
This code deals with some complex promises and wait loops. It would be a lot easier to read if converted to async / await.
This test times out sometimes when Travis is overloaded. Perhaps we just need to increase the timeout. Or maybe some I/O heavy parts can be mocked further.
1) amoClient.Client signing lets you sign an add-on:
Error: timeout of 1000ms exceeded. Ensure the done() callback is being called in this test.
at tryCatchReject (node_modules/when/lib/makePromise.js:845:30)
at runContinuation1 (node_modules/when/lib/makePromise.js:804:4)
at Fulfilled.when (node_modules/when/lib/makePromise.js:592:4)
at Pending.run (node_modules/when/lib/makePromise.js:483:13)
at Scheduler._drain (node_modules/when/lib/Scheduler.js:62:19)
at Scheduler.drain (node_modules/when/lib/Scheduler.js:27:9)
To reproduce, create a web extension with a manifest that will create an error. For example, enter an invalid app version:
{
"manifest_version": 2,
"name": "some-extension",
"version": "1.0",
"applications": {
"gecko": {
"strict_min_version": "48.0.0"
}
},
}
web-ext sign
results in a confusing timeout. You can see the real error in the API response. Additionally, the rejected promise is not handled. Both of these issues should be fixed.
$ web-ext sign --verbose --api-key ... --api-secret ... --api-url-prefix https://addons-dev.allizom.org/api/v3
Version: 1.2.1
[util/temp-dir.js][debug] Created temporary directory: /var/folders/h7/rttdqkks7fl_txp9_rr4j4840000gn/T/tmp-web-ext-182130JL93PwouZQ9
[util/manifest.js][debug] Validating manifest at /Users/kumar/dev/webextensions-examples/beastify/manifest.json
[cmd/build.js][info] Building web extension from /Users/kumar/dev/webextensions-examples/beastify
[cmd/build.js][debug] Using manifest id=[not specified]
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/.web-extension-id
[cmd/sign.js][debug] Found extension ID {cf3c69a7-f889-447c-9d6b-7694be803513} in /Users/kumar/dev/webextensions-examples/beastify/.web-extension-id
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.0-fx+an.xpi
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.0-fx.xpi
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.0.xpi
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.0.zip
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.1-fx+an.xpi
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.2-fx+an.xpi
[cmd/build.js][debug] FileFilter: ignoring file /Users/kumar/dev/webextensions-examples/beastify/web-ext-artifacts/beastify-1.3-fx+an.xpi
[cmd/build.js][info] Your web extension is ready: /var/folders/h7/rttdqkks7fl_txp9_rr4j4840000gn/T/tmp-web-ext-182130JL93PwouZQ9/beastify-1.0.zip
[cmd/sign.js][info] Using previously auto-generated extension ID: {cf3c69a7-f889-447c-9d6b-7694be803513}
[sign-addon] [API] -> { url: 'https://addons-dev.allizom.org/api/v3/addons/%7Bcf3c69a7-f889-447c-9d6b-7694be803513%7D/versions/1.0/',
formData:
{ upload:
ReadStream {
_readableState: [Object],
readable: true,
domain: null,
_events: [Object],
_eventsCount: 1,
_maxListeners: undefined,
path: '/var/folders/h7/rttdqkks7fl_txp9_rr4j4840000gn/T/tmp-web-ext-182130JL93PwouZQ9/beastify-1.0.zip',
fd: null,
flags: 'r',
mode: 438,
start: undefined,
end: undefined,
autoClose: true,
pos: undefined } },
headers: { Authorization: '<REDACTED>', Accept: 'application/json' } }
[sign-addon] [API] <- { headers:
{ allow: 'GET, POST, PUT, HEAD, OPTIONS',
'content-security-policy': 'script-src \'self\' https://addons.mozilla.org https://www.paypalobjects.com https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://ssl.google-analytics.com https://addons.cdn.mozilla.net https://addons-dev.allizom.org https://addons-dev-cdn.allizom.org; default-src \'self\'; img-src \'self\' data: blob: https://www.paypal.com https://ssl.google-analytics.com https://addons.cdn.mozilla.net https://static.addons.mozilla.net https://sentry.prod.mozaws.net https://addons-dev-cdn.allizom.org; media-src https://videos.cdn.mozilla.net; style-src \'self\' \'unsafe-inline\' https://addons.cdn.mozilla.net https://addons-dev-cdn.allizom.org; frame-src \'self\' https://ic.paypal.com https://paypal.com https://www.google.com/recaptcha/ https://www.paypal.com https://www.sandbox.paypal.com; object-src \'none\'; connect-src \'self\' https://sentry.prod.mozaws.net; font-src \'self\' https://addons.cdn.mozilla.net https://addons-dev-cdn.allizom.org; report-uri /__cspreport__',
'content-type': 'application/json',
date: 'Wed, 13 Jul 2016 18:28:10 GMT',
etag: '"6a28808457067e35459e2966aeaaa1a2"',
server: 'nginx',
'set-cookie': '<REDACTED>',
'strict-transport-security': 'max-age=31536000',
vary: 'X-Mobile, User-Agent',
'x-backend-server': 'ip-172-31-21-135',
'x-content-type-options': 'nosniff',
'x-frame-options': 'DENY',
'x-xss-protection': '1; mode=block',
'content-length': '128',
connection: 'Close' },
response: { error: 'Cannot find min/max version. Maybe "strict_min_version" or "strict_max_version" contains an unsupported version?' } }
Potentially unhandled rejection [1] Error: request URL was not specified
at Client.configureRequest (/Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:733:16)
at /Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:783:31
at init (/Users/kumar/dev/web-ext/node_modules/when/lib/makePromise.js:39:5)
at new Promise (/Users/kumar/dev/web-ext/node_modules/when/lib/makePromise.js:27:53)
at Function.promise (/Users/kumar/dev/web-ext/node_modules/when/when.js:97:10)
at Client.request (/Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:782:30)
at Client.get (/Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:645:28)
at checkSignedStatus (/Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:471:19)
at /Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:517:10
at init (/Users/kumar/dev/web-ext/node_modules/when/lib/makePromise.js:39:5)
Validating add-on [..........................................................................................................................................................................................................................................................]
[util/temp-dir.js][debug] Removing temporary directory: /var/folders/h7/rttdqkks7fl_txp9_rr4j4840000gn/T/tmp-web-ext-182130JL93PwouZQ9
[program.js][error]
sign: Error: Validation took too long to complete; last status: [null]
at [object Object]._onTimeout (/Users/kumar/dev/web-ext/node_modules/sign-addon/dist/sign-addon.js:522:19)
at Timer.listOnTimeout (timers.js:92:15)
When signed files are fetched from the AMO web service, they are downloaded to some directory. It might be nice to pipe it to a buffer instead and offer it as a parameter on the returned result
object. This is what zip-dir does by default, for example.
commitlint
is quite confusing for contributors (including... me). We could remove it and create a script that helps the release manager by pre-generating a GitHub release description based on git log
.
Since web-ext
dropped support for Node 6 in 3.0.0, sign-addon
can do the same.
This issue is about:
sign-addon
no longer supports Node 6web-ext
currently supports(because, why not?)
The code is a bit old and the test suite missed an error previously. We need to update it in #323 so adding static types would probably help.
We can use https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc
Since all NPM upload tokens have been revoked a new one needs to be created and added to travis.yml
I'm attempting to import the module from npm for use as per the README. However, I'm getting various errors which seem to be missing dependencies, that I typically expect the package to provide (especially as some have multiple values), rather than having to provide myself
In my script:
``js
var signAddon = require('sign-addon');
My package.json started with just `"sign-addon": "0.0.1",` I then had to find and add modules for the items below - as the dist file in the node_modules directory didn't include them.
```shell
module.js:338
throw err;
^
Error: Cannot find module 'source-map-support'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:278:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:1:63)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
Error: Cannot find module 'any-promise'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:278:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:244:19)
at __webpack_require__ (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:22:30)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:180:16)
at __webpack_require__ (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:22:30)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:57:12)
at __webpack_require__ (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:22:30)
Error: Cannot find module 'thenify-all'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:278:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:262:19)
at __webpack_require__ (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:22:30)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:222:2)
at __webpack_require__ (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:22:30)
at Object.<anonymous> (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:57:12)
at __webpack_require__ (/Users/mark/loop/loop/node_modules/sign-addon/dist/sign-addon.js:22:30)
For some reason, if some javascript file has a syntax error, the webpack build will appear to fail but it will only issue a warning. This causes the tests to run using the last build and thus will pass every time. We should make the tests fail if there is a syntax error. This probably only affects local development where you will be continuously editing code and running tests.
Once the API supports submitting a new listed add-on, sign-addon
needs to support it so that web-ext
can use it in mozilla/web-ext#804.
Submitting to a listed/unlisted channel is possible as of #248 but this won't work for submitting new add-ons because the API needs to collect additional metadata and that requires API changes (https://github.com/mozilla/addons-server/issues/7811).
I know that "sign addon" isn't the most aptly named module for add-on submission but sign-addon
already has all the plumbing to work with the AMO API so we might as well start here.
I think we should add a .npmignore
so that our .gitignore
isn't used in its place. The main thing is that .gitignore
ignores dist/*
but that's crucial for npm since we need the compiled module to be published.
When you specify downloadDir
and an xpi file with the same name exists in that directory, it will be overwritten. We should stop doing that by default and introduce another option like overwriteDestination: true
to allow overwrites. Keep in mind that it would be very hard to encounter this scenario in real life because the API won't let you sign the same version twice.
Instead of injecting props only for testing, we could rely on the Jest Timer Mocks and get rid of most of the _clearXXX
, _setXXX
, etc.
With add-on beta channel removal on 2/22/2018, it would be more than useful to have a way to automate add-on signing for beta versions to be hosted on the developer site.
This implies being able to upload unlisted add-ons and this does not seem to be possible for now with the current sign-addon module.
Reference: web-ext issue 877
The current signing code is written in a promise chain style but there are several parts that need to wait in a loop for conditions to be met before proceeding. Promise chains are terrible for this kind of logic. I think it would be better to try re-writing this in a reactive pattern.
I see that PseudoProgress.spec.js crept in which means we have a *.spec
file mixed with test.*
files. We should pick one naming format and make it consistent.
Currently, signAddon()
can only be used programmatically. We should add a simple command line script, maybe with yargs.
Since we use squash-and-merge, linting commit messages for changelog formatting no longer makes sense.
Let's lint the PR titles instead, like how web-ext does it: https://github.com/mozilla/web-ext/blob/master/tasks/travis-pr-title-lint.js
All old code was using when but we can use ES6 promises now. All conversions should be straight forward and Promise
is already shimmed by webpack and available.
STR:
sign-addon
mastersign-addon
clone, do npm install; npm start
and npm link
npm install web-ext
and then npm link sign-addon
as per README.md
web-ext
with credentials to create a new version of your add-onExpected results:
Actual results:
[cmd/sign.js][warn] No extension ID specified (it will be auto-generated)
[sign-addon] Signing add-on without an ID
[sign-addon] [API] POST request:
{ url: 'http://olympia.test/api/v3/addons/',
formData:
{ upload:
{ _readableState: [Object],
readable: true,
_events: [Object],
_eventsCount: 1,
_maxListeners: undefined,
path: '/tmp/tmp-web-ext-15869ra76OCCsC1tI/something_-1.1.zip',
fd: null,
flags: 'r',
mode: 438,
start: undefined,
end: Infinity,
autoClose: true,
pos: undefined,
bytesRead: 0,
closed: false },
version: '1.1' },
timeout: 300500,
headers: { Authorization: '<REDACTED>', Accept: 'application/json' } }
[util/temp-dir.js][debug] Removing temporary directory: /tmp/tmp-web-ext-15869ra76OCCsC1tI
[program.js][error]
TypeError: Cannot read property 'headers' of undefined
at absoluteURL (/home/mat/work/mozilla/sign-addon/dist/webpack:/src/amo-client.js:500:18)
[program.js][debug] Command executed: sign
Notes:
master
. It works fine if I git checkout 0.3.1
in my sign-addon
clone and re-run npm install
and npm start
to rebuild the 0.3.1 version.This is the error I receive:
Server response: Missing "upload" key in multipart file data. ( status: 400 )
I believe my xpi is good, since it's the same I'm sending to jpm. Any idea or something else I can try?
currently I'm calling jpm from the code for the signing process, it would be nicer for my app to use that module instead so now I'm trying this separated module.
It should be possible to remove grunt in favour of simpler run scripts.
I know it does not seem urgent but this project has weird/inconsistent conventions and it is quite hard to make changes without ending up with a large diff. I think applying Prettier would help.
Looking at using this for uploading an xpi, I need to extract the id and version from the xpi.
It would be more convenient if we could move some of the functions from https://github.com/mozilla-jetpack/jpm/blob/1.0.7/lib/utils.js so that we could have it all in one package, rather than needing two packages.
Not sure how active this project is, but it may be worth trying to integrate greenkeeper or renovate (the latter allows you to schedule updates to a certain day/time, which makes it a bit less noisy).
Newer versions of npm (npm@6 or [email protected]) have a new $ npm audit command which is similar to the old nsp module, which detects potential vulnerable modules. You can sort of hack an audit right meow by using npx [if you're using [email protected]+], like so:
$ git clone https://github.com/mozilla/sign-addon.git && cd sign-addon
$ npm install
$ npx npm@6 audit
...
[!] 32 vulnerabilities found - Packages audited: 7381 (7261 dev, 222 optional)
Severity: 13 Low | 17 Moderate | 2 Critical
And to get a list of all current outdated modules, we can use good ol' $ npm outdated:
$ npm outdated
Package Current Wanted Latest Location
babel-polyfill 6.9.1 6.16.0 6.26.0 sign-addon
es6-error 3.0.1 4.0.0 4.1.1 sign-addon
es6-promisify 4.1.0 5.0.0 6.0.0 sign-addon
jsonwebtoken 7.1.7 7.1.9 8.2.1 sign-addon
mz 2.4.0 2.5.0 2.7.0 sign-addon
request 2.74.0 2.79.0 2.86.0 sign-addon
source-map-support 0.4.2 0.4.6 0.5.6 sign-addon
chai 3.5.0 3.5.0 4.1.2 sign-addon
grunt 1.0.1 1.0.1 1.0.2 sign-addon
grunt-contrib-clean 1.0.0 1.0.0 1.1.0 sign-addon
grunt-contrib-watch 1.0.0 1.0.0 1.1.0 sign-addon
grunt-eslint 19.0.0 19.0.0 20.1.0 sign-addon
grunt-newer 1.2.0 1.2.0 1.3.0 sign-addon
when 3.7.7 3.7.7 3.7.8 sign-addon
I was trying to setup a CI for build & sign a webextension at each push when I encountered a timeout each time I was calling the web-ext sign
command.
It appears that it happens if you try to sign an already signed version of an addon, in my case the version haven't be incremented in the last commit.
Stacktrace:
sign: Error: Validation took too long to complete;
at Timeout._onTimeout (C:\NPM\Modules\node_modules\web-ext\node_modules\sign-addon\dist\webpack:\src\amo-client.js:222:16)
at tryOnTimeout (timers.js:224:11)
at Timer.listOnTimeout (timers.js:198:5)
I am fine with not signing an already signed version but it is preferable to have a precise exception than a timeout.
As part of the AMO review process, some extensions are required to supply the source code in a zip file.
https://extensionworkshop.com/documentation/publish/source-code-submission/
Please add the option to submit the source code.
We should expose the ability to use a proxy server for those that require one. It should be as simple a change as:
requestConf.proxy = 'http://myproxy:proxyport';
See configureRequest().
Given that we are using mocha
, we can use https://github.com/istanbuljs/nyc. We can also add codecov
.
We should update the ESLint configuration to:
If you do something like web-ext sign --verbose
(which calls signAddon({verbose: true})
) then you get a log of API responses. However, the files array is not shown. This is crucial part of the output for debugging purposes so we should show it. Example:
response:
{ guid: '[email protected]',
active: false,
automated_signing: true,
url: 'https://addons.mozilla.org/api/v3/addons/[email protected]/versions/1.0rc6/uploads/94b362a2b65f482aa6bf54397dbbb976/',
files: [ [Object] ],
passed_review: false,
pk: '94b362a2b65f482aa6bf54397dbbb976',
processed: true,
reviewed: false,
valid: true,
validation_results:
{ errors: 0,
success: true,
warnings: 0,
messages: [Object],
passed_auto_validation: true,
ending_tier: 5,
compatibility_summary: [Object],
detected_type: 'extension',
signing_summary: [Object],
notices: 1,
signing_ignored_summary: [Object],
metadata: [Object] },
validation_url: 'https://addons.mozilla.org/en-US/developers/upload/94b362a2b65f482aa6bf54397dbbb976',
version: '1.0rc6' } }
I originally described this as a comment in #319 but it deserves its own separate issue.
Validation and Signing are two separate things, and the API does differentiate between the two, allowing web-ext
to give more accurate feedback about what's going on behind the scenes when signing. I think because they are separate concepts and because the API does return the information already, separating validation and signing pseudo progression bars would be nice to have.
It might even makes sense for web-ext
to return without an error when the timeout for signing has been reached, but the upload is marked as valid
: It would mean that although the add-on passed linting and basic validation rules, signing has not been done yet, for whatever reason, but is expected to happen eventually.
We already have code that does this for listed uploads, relying on the automated_signing
property returned by AMO API, but that property has been a bit misleading for a while: A lot of uploads are now auto-approved, even listed
, but we still (currently and in the future) return "automated_signing": false
for those.
Here is how I think it should work from a user perspective:
Validating add-on
pseudo progress bar is marked as finished as soon as polling detects valid
is true
on the upload, otherwise reports an error and terminates the processSigning add-on
signed
is true
, everything behaves as beforeYour add-on has been submitted for review. It passed but could not be automatically signed, you'll receive an email when it is available for download
and terminate.You may receive an error from the API server like:
{"detail":"Signature has expired."}
this has nothing to with signing an extension so it's confusing. All server errors should be prefixed, maybe like:
{"detail":"Error communicating with the signing service: Signature has expired."}
Original bug report: mozilla/addons#661 (includes a verbose web-ext sign
log)
I think these are the steps to reproduce but I haven't confirmed it:
web-ext sign
to create an unlisted add-onweb-ext sign
to sign 2.0.0web-ext sign
to sign 2.0.0 againThis should work since the old version had been deleted.
The test in tests/test.amo-client.js
named 'makes requests with an auth token' sometimes fails. I think it is related to the timing of checking a JWT (which naturally involves timestamps).
All internal exceptions are thrown as Error
. It would be nice to throw them as a custom class, like SigningError
, so they could be handled upstream.
In https://github.com/mozilla/addons-server/issues/12622 AMO is going to refactor the way unlisted submissions are handled, and have them go through the same auto-approval process as listed ones.
Validation and signing will continue to be automatic, but signing will no longer directly follow validation and may take more time to complete than before. This is an issue because sign-addon
expects signing to be almost instantaneous and has a 2 minutes timeout before reporting an error. That timeout needs to be updated to a higher value to leave time for signing to succeed.
The value of the timeout we need is currently being discussed, I'll add it to this issue as soon as possible.
While releasing a new tagged release from the web-ext repo, I noticed that the travis job wasn't able to successfully run the deploy task (it did fail with this error: https://travis-ci.org/mozilla/web-ext/jobs/649392805#L283-L284).
It is not unlikely that sign-addon may trigger the same issue once we are going to release the next tagged release.
mozilla/web-ext#1838 contains the changes that we applied to the web-ext travis config to successfully deploy the new npm package from the travis job.
If the sign-addon travis config does trigger the same issue, then we may want to apply the same kind of changes to this repo as well (otherwise we can defer the change once migrating to travis dpl v2 format does become mandatory).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.