I run a self-hosted auto-updating Firefox add-on being used by several million people. I am informed that I will need to "sign" it soon or it will quit working. (Deadlines are unclear; it seems like it may be as soon as June 30th.) I am looking for exact instructions as to how to make this happen.
I am not finding these instructions, so I am doing my best to puzzle things out.
Googling for things like "how to sign a firefox add-on" get me a lot of false leads. Mozilla should take down or at least modify these pages with current information:
https://developer.mozilla.org/en-US/docs/Signing_a_XPI
https://developer.mozilla.org/en-US/docs/Signing_an_extension
https://developer.mozilla.org/en-US/Add-ons/SDK
(That last is a grossly time-wasting false lead; I updated my old cfx installation to 1.17, went through the full shebang, and then discovered I really needed to be running jpm. Growl.)
https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/cfx_to_jpm
I get jpm and instantly bump my nose against new version numbering requirements. Looks like jpm wants X.Y.Z, but we have been using X.YY since the dawn of time. New rules are not compatible with several years' worth of analytic data. So I rename our version to X.YY.0 and prepare to watch my data people roll on the floor and tear their hair out.
Also, jpm won't take --update-link and --update-url. I have a bad feeling about this.
Finally, jpm complains when I have uppercase letters in the name of the extension. (Something about node.js standards, which makes no sense to me in the context of building a browser extension.) Kind of hoping I can get away with renaming files later, since we have a lot of URLs with mixed case.
https://wiki.mozilla.org/Addons/Extension_Signing
How do I get my add-ons signed if they are not hosted on AMO?
You will need to create an AMO account and submit your add-on. There will be an option where you indicate the add-on isn't hosted on AMO, and you'll be able to submit your add-on files without having them published on the site.
There are repeated references to something called "AMO" throughout this page. Not sure what this stands for and there are no links anywhere. Googling plus educated guesswork reveals that AMO stands for addons.mozilla.org. Mozilla needs to figure out branding here; these things are browser extensions, and calling them "add-ons" is horribly confusing.
Off I go. AMO wants me to log in. I am super puzzled as to why I can't log in with a GitHub account or Firefox persona, same as I do on developer.mozilla.org. I do what I usually do: try password recovery for the personal e-mail address I've been using for a hundred years on these things, yes, that works, reset password, change to something new. Then log in. Naturally the redirect doesn't work and it dumps me out to the front page at AMO, where I need to figure out what page I really wanted after logging in.
Aha, here we are:
https://addons.mozilla.org/en-US/developers/addon/submit/1
I upload the xpi that jpm built. (Another serious concern: jpm is building a file named something like this: jid1-dEadBeefWooYay@jetpack-1.37.0.xpi. Is it safe to rename this file? All my self-hosted download links point to a different name.)
It passes, yay, but warns me that it's missing the updateURL element, the crucial part that tells Firefox where to look for updated versions. This used to be something you passed on the command line to cfx. After poking around some more I find it here:
https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/package_json
Looks like updateURL wants to go in package.json like this:
"updateURL": "https://cdn.myserver.com/ext/My_Extension.update.rdf"
I am praying that I'm supposed to put the link to update.rdf in here and not the direct link to the extension download. If this is wrong and people install it I don't think I'll ever be able to update them, right?
When I run jpm xpi with an updateURL, I don't get My_Extension.update.rdf any more the way I used to. Do I now need to hand-whittle this file?
Next attempt to validate fails; updateURL is "banned."
Okay, fine. Pull it, let's just see if we can get something to sign.
Next attempt to validate passes except for scary note about components and bootstrap, which as far as I know I am stuck with:
Access to the `Components` global
Warning: Access to the `Components` property is deprecated for security or other reasons.
bootstrap.js
const { utils: Cu } = Components;
const rootURI = __SCRIPT_URI_SPEC__.replace("bootstrap.js", "");
Take XPI, try it out on Firefox 38. Works!
Take XPI, try it out on Firefox 29. Does not work; the scary note here:
https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/cfx_to_jpm
... made me suspect it wouldn't.
Adding minVersion and maxVersion members to package.json make no difference. So in the time-honored approach I've always take to to modifying the download file name, I unzip the xpi, hack minVersion and maxVersion, rezip, and rename. Dropping this file into Firefox gets me a corrupt file warning.
So, next question: will users below Firefox 38 even be able to use our signed extension?
More from the FAQ:
How does the signing process work?
Files submitted for signing will go through an automated review process. If they pass this review, they are automatically signed and sent back to the developer. This process should normally take seconds. If the file doesn't pass review, the developer will have the option to request a manual review, which should take less than two days. This is not the same process that currently applies to AMO add-ons, which has been typically slower.
How should I expect the signed file to get back to me? E-mail to the address I used to sign up for AMO? If so, this hasn't happened yet.
When I get the signed version back, will the add-on be irrevocably associated with the AMO account I used to sign it? Are there "teams," so I can allow fellow workers to do this? If I'm hit by a bus and have not passed my account along, are they screwed?
Currently stuck on page 2 of validation process. The button labeled Continue at the bottom of the page reloads it and tells me "This name is already in use. Please choose another."
I second @potch and others by saying thank you for taking these notes and pointing out flaws and papercuts in the process.
As for jpm's ugly filenames, I filed bug 1153954 about that recently, because I didn't like that either. Yes, it's safe to rename.