Firefox Stable and Beta soon will allow only signed extensions

[mikhaelkh]

Firefox 40 beta just released, which warns this extension is unsigned. Starting from version 41, Firefox will enforce extension signature. More info here. While is has been published on addons.mozilla.org, your official site still provedes unsigned version.

[reedy]

Thanks for the heads up :)

[jsha]

Update on this: we've been working with Mozilla on getting their second signature (besides EFF's normal signature) on HTTPS Everywhere. This turned out to be way more complicated than we expected.

To get a signature for a self-hosted addon, you need to have an unlisted version of your extension on AMO, upload that version for validation, and get a signature back. Problems so far:

• The unlisted xpi is slightly different from one you would upload to be hosted on AMO: It includes an updateKey and updateURL in install.rdf. We already dealt with this when we first started uploading to AMO in parallel with uploading to eff.org.
• However, previously the eff.org hosted version and the AMO hosted version had the same name and id field in the XPI. AMO won't allow you to have a listed and an unlisted extension that share a name and id field. So we need to rename one or the other.
• Unlisted addons are supposed to be subject to a fast, automatic review so you can get the AMO signature immediately. However, HTTPS Everywhere is complex enough / uses powerful enough APIs that it triggers a manual review every time we upload a copy for signing. That means that, currently, each release has to wait about two days for manual review. Mozilla is working on improving the review process so that certain pieces of code can be whitelisted and not trigger manual review in the future, but it probably won't be ready in time for launch.
• Once our unlisted version goes through manual review, we can download an AMO-signed copy. Once we have that, we need to finish the release by signing an update.rdf for it using our own, offline key, and uploading the XPI to eff.org. Note that since AMO signs the XPI, and we sign the update.rdf, we can have two signatures on each update and they will both be verified.

There's an additional complication: Even though we've been uploading a copy to AMO since 4.0.0, we are still stuck on the review queue for AMO hosting. AMO has historically relied on volunteers to review add-ons, and there is a lot of work, so the queue moves slowly. As a result, even though you can download HTTPSE from a direct link at https://addons.mozilla.org/en/firefox/addon/https-everywhere/, it's not listed in search results on AMO. Once we pass manual review for the main AMO queue (which is a different standard than the manual review for the unlisted queue, which moves much faster), then HTTPSE will show up in search results on AMO. One thing we're not clear on yet: If we upload a new version to the AMO-hosted, listed instance of the extension, how quickly will it update? Right now it seems like updates to that copy go live right away. But it's possible future updates to that copy may need to go through the manual queue again, which creates a weird situation where there are two copies of the extension waiting for two reviews at different standards, and one of them may be newer than the other. So we're considering that we may only want to host on eff.org and not AMO, since we expect faster turnaround on those releases. The downside is that users do search for HTTPSE in AMO, and we'd like them to be able to find us there.

[Mikaela]

Allowing only signed messages has arrived to Firefox Developer Edition (Mozilla Firefox 41.0a2) and soon more people will probably be reporting this.

[numismatika]

@Mikaela for now one can always do "
The workaround is to set xpinstall.signatures.required to false (but this is clearly not optimal)."
I think people using nightlies and the developer edition will find this setting.

[Mikaela]

I don't even consider that workaround as I don't like disabling security features*. At the moment the only HTTPS Everywhere is the only unsigned extension.

*with exception of some like Secure Boot which just are too restricting.

[X-dark]

@numismatika This workaround is only working for Nightly and Dev version of FF. They explicitly said that release version will not be able to disable signature checking.

Firefox Release and Beta versions will not have any way to disable signature checks. Checks can be disabled in other versions, as described in detail below.
https://wiki.mozilla.org/Addons/Extension_Signing#FAQ

[jsha]

The upcoming release version will only warn about unsigned add-ons. The plan for Firefox's next release is to block with an opt-out, and the next one will block with no opt-out.

I did some more work on this today, and found that AMO's signature mechanism is giving me an XPI which Firefox rejects as corrupt. I've emailed Mozilla and we'll take it from here.

[jsha]

Update: I can now get an uncorrupted signed package from AMO. The latest problem: In order to get a signature on our extension, we need to create an 'unlisted' entry on AMO to upload. AMO doesn't allow two extensions to have the same id field, even if one is listed and the other is unlisted.

We currently have a version on AMO that is in the review queue to be a listed extension: https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/. It's been in the queue for about nine months, and is downloadable from AMO but is not findable in search because it hasn't been reviewed yet. But we've got about 16k users on the 'to-be-listed' AMO version.

So to get our unlisted signature I created a separate entry on AMO with a different id field. Unfortunately, Firefox will not update an extension if the updated extension differs in id field. So even though I can get a signed XPI for self hosting, none of the existing installation of HTTPS Everywhere will update to it.

One solution would be for AMO to allow our listed an unlisted extension to have the same id. I've reached out to Mozilla for help.

[q--]

https://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility says

Note: It is possible to change the id of add-on through add-on update. To do this, just provide new em:id in install.rdf within new xpi file, and put its url in em:updateLink in update.rdf.

[baptistem]

According to this https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ and https://wiki.mozilla.org/Addons/Extension_Signing#FAQ FF dev edition will have a way to allow unsigned extentions. So far I don't see it on 410a2 I'll test on nightly

[welwood08]

@baptistem See #2467 (comment) - it's not really a useful solution though since not everyone uses dev edition.

[baptistem]

@welwood08 at least it helps to test! but yeah it's not a "clean" workaround.

[hpvd]

updating to FF41b1 on Win disabled https everywhere.
switching xpinstall.signatures.required to false also works in this beta as a TEMPORARY workaround (thought it wouldn't work any more entering beta state)

[jsha]

Fixed with version 5.1.0.

[PotcFdk]

Does that mean you've found a solution to the main issue that you described earlier (i.e. needing a listed and unlisted addon, possibly with the same id field)?

[jsha]

Yep! As @baptistem pointed out, it's possible to use the update mechanism to change the id of an addon. So version 5.1.0 has id https-everywhere-eff@eff.org where 5.0.9 had https-everywhere@eff.org.

[X-dark]

Installing the 5.1.0.xpi (ie not the -eff version) make Firefox thinks it is a different add-on and thus installs it alongside 5.0.9. After removing 5.0.9 everything is fine.

[jsha]

Good point, thanks! For people with 5.0.9 installed, auto-update should replace the old version. I assume you installed 5.1.0 manually?

There's going to be a similar issue for people who install from EFF and AMO: We'll have two copies of the extension living alongside each other with different ids. This is why I was pushing Mozilla to sign our existing extension without forcing us to change the id. We may want to add some special logic to detect when both ids are present, and one version can kick the other out of the nest, so to speak.

[X-dark]

Yes I installed it manually. Auto-update did not replace 5.0.9, but maybe I did not wait long enough.

[Liudvikam]

Installing the 5.1.0.xpi (ie not the -eff version)

How does the -eff version of 5.1.0 differ from the normal version?

[jsha]

How does the -eff version of 5.1.0 differ from the normal version?

They don't differ. New files from here on will be named with -eff to indicate the new id in install.rdf.

For the 5.1.0 release, script that generates our update.rdf was hardcoded to point at https-everywhere-VERSION.xpi, so I just created a symlink on the server. This will be fixed in the next version.

[q--]

@Liudvikam Different update URL. Updating through the EFF's own servers instead of AMO should give faster updates and more privacy. (Mozilla requires all add-on updates to be manually verified first.)

[Liudvikam]

Okay. Thanks.

[jsha]

@q--: It's a little more complicated than that. Both of the versions listed on eff.org/https-everywhere update through EFF's servers, it's just a temporary naming quirk. The AMO version can only be downloaded through AMO itself.

Also, in theory, the AMO updates are manually verified and the EFF hosted ones aren't. But with Mozilla's new code signing requirements, we have to upload the EFF hosted one to Mozilla for signing. In theory that signing happens automatically, but HTTPS Everywhere always flags for manual review because it uses ctypes. So for now, both versions are delayed by manual review. :-( However, Mozilla plans to add whitelisting for certain flag types so we can hopefully skip manual review for self-hosted in the future.

[polyzen]

It appears that there is now an API for extension signing: https://olympia.readthedocs.org/en/latest/topics/api/signing.html. Hopefully someone can look into this.

mozilla/pdf.js#6137 (comment) by @timvandermeij

[metbril]

Extension version 5.1.2 is working when installing from EFF website, but disabled after restart. Running FF 43.0.4 on Mac OSX.