Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#47395 - [firefox-{adblock-plus,noscript,firebug,raismth}] missing signatures for Firefox 43+

Attached to Project: Community Packages
Opened by Eli Schwartz (eschwartz) - Tuesday, 15 December 2015, 23:52 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 04 December 2017, 22:57 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To speps (archspeps)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No

Details

Firefox 43 i̶s̶ ̶s̶c̶h̶e̶d̶u̶l̶e̶d̶ ̶t̶o̶ enforces extension signing, and Firefox 44 is scheduled to disable the about:config override that allows you to ignore that.
https://wiki.mozilla.org/Add-ons/Extension_Signing


This breaks (some) extensions which are installed to /usr/lib/firefox/browser/extensions/*
For example, the Arch packages:
* community/firefox-adblock-plus 2.6.11-1
* community/firefox-noscript 2.6.9.39-1
* community/firefox-firebug 2.0.8-1
* community/firefox-raismth 4.0.1-1

As well as many similar packages in the AUR.


All these extensions currently show warnings in about:addons and now that Firefox 43 .

Hopefully there is some way of disabling this check going forward -- I believe unbranded builds and the Developer builds will continue to allow the preference?
At the very least, users should be allowed to specify that they wish to ignore signing requirements, and *perhaps* this preference should be installed in vendor.js


A fix can be applied if the extension has been "fully reviewed", but it is necessary make sure the META-INF folder has full read permissions.
It seems extensions are created with META-INF/* having permissions 600 and when unzipped only root can read them. :o


Unfortunately it seems Adblock Plus is too useful (i.e. complex) to (usually) get fully reviewed in a reasonable timeframe. Although for the first time ever, they got it reviewed on time? So, hope for the future I guess...
This also breaks every AUR extension which build from git.

So I for one would still like to see this so-called feature disabled. Cue subjective rant about protecting Windows users by taking away user choice. ;)


Attached are some patches that build the current community/firefox-* extensions in a way that validates with Firefox.

(Firebug is also updated to the latest version. As is Adblock Plus. I realized as I wrote this that they updated today. Shockingly, it was reviewed on time I guess. But they MUST be downloaded from AMO.)
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 04 December 2017, 22:57 GMT
Reason for closing:  Fixed
Additional comments about closing:  All packages have either been fixed or dropped from the repos.
Comment by Doug Newgard (Scimmia) - Wednesday, 16 December 2015, 07:31 GMT
So you're proposing changing the extension packages, not the firefox package? You talk about wanting to see the feature disabled, but seem to imply that's not possible?
Comment by Evangelos Foutras (foutrelis) - Wednesday, 16 December 2015, 07:48 GMT
I might have been too quick to close this as a duplicate of  FS#45900 . While I do not see us reverting any upstream decision in regard to the signing requirement, I suppose the packaged extensions should either be fixed or removed.
Comment by Eli Schwartz (eschwartz) - Thursday, 17 December 2015, 00:18 GMT
Didn't see that other bug, sorry.

I'd like to see the feature disabled. (I am not sure of the precise implications re: official branding, are they really fundamentally tied together? Any uncertainty is simply down to me not knowing much about building Firefox.)
But I also think extensions should be packaged in the *best* way possible, regardless of Arch's decision about Firefox itself.

...

If mandatory extension signing is left on, then the extension packages are fundamentally broken without my fixes. As of the current published versions, they all work properly with my fixes. Obviously it is up to Mozilla to actually approve any updates.
If mandatory extension signing is turned off, it is still more "proper" to package them in a way that doesn't depend on having it turned off. And what if someone rebuilt Firefox themself with it turned on?

...

I opened this bug report intending it be about Firefox itself, and extension packages by association, but I guess since we already have a bug about Firefox, this bug should just be about the extensions. Can you change the title from "extension signing and the future" to "missing signatures for Firefox 43+".

...

Although this will totally break aur/firefox-extension-https-everywhere, the new version has been waiting to be signed since August. :(
Comment by Chih-Hsuan Yen (yan12125) - Friday, 18 December 2015, 09:53 GMT
I've posted a patch for extra/firefox to https://bugs.archlinux.org/task/47432.
Comment by Chih-Hsuan Yen (yan12125) - Friday, 18 December 2015, 12:26 GMT
One more side note: bsdtar used by makepkg is buggy ( FS#47436 ). We should either fix libarchive or use unzip.
Comment by Eli Schwartz (eschwartz) - Friday, 18 December 2015, 15:19 GMT
Yen Chi Hsuan,

Did you not see the bug which is linked in comment #2?

The Arch devs have made the decision that extra/firefox should follow Mozilla and keep extension verification.
While I personally disagree with that move, it is not my decision to make, and it is *already* covered by  FS#45900  .

The only remaining question is regarding the packaging of extensions. Which this bug should fix -- since it is incongruous to ship an extension in the repos when it doesn't work.
Comment by Pablo Lezaeta (Jristz) - Sunday, 03 January 2016, 03:34 GMT
Also it break arch-firefox-search [1] wich I think is official Arch project since Upstream point to Archlinux

[1] https://www.archlinux.org/packages/community/any/arch-firefox-search/
Comment by Connor Behan (connorbehan) - Sunday, 03 January 2016, 05:59 GMT
The  FS#45900  decision to stick with --enable-official-branding even though it makes Arch's Firefox useless for addon developers is absurd. Responses like "this is what upstream intends" are missing the point because they also intend Firefox to be primarily used by people with no desire to use a do-it-yourself distro or indeed any distro of Linux.
Comment by Chih-Hsuan Yen (yan12125) - Sunday, 03 January 2016, 10:37 GMT
I have once tried to disable signature verification for distro addons (see my previous comments and patches), but now I believe keeping verification is the correct way. For addon developers, it's possible to sign their addons programatically with nodejs-jpm with [1] and [2] landed.

[1] https://github.com/mozilla-jetpack/jpm/pull/437
[2] https://github.com/mozilla-jetpack/jpm/pull/443
Comment by Connor Behan (connorbehan) - Sunday, 03 January 2016, 17:43 GMT
So now instead of bypassing verification in about:config, you run somebody's untrusted addon by opening it up in Jetpack and then signing it with your own untrusted key? Anyway, I will keep patching my Firefox because I also want to be able to use XUL overlay addons before they have gone through the bureaucracy.
Comment by Eli Schwartz (eschwartz) - Monday, 04 January 2016, 20:13 GMT
Connor -- while I agree with you that the decision was unfortunate, and I have rebuilt Firefox with Yen Chi Hsuan's patch (to tell Firefox that pacman/root is trusted to bypass extension signing), it appears (per the resolution of  FS#45900 ) that the official Arch policy is "intent of upstream trumps user-centrism".

Anyway, this bug exists to try to make the best of a bad situation, not to debate whether  FS#45900  should have been closed.

...

jpm -- I thought that creates an unlisted addon, which cannot be "sideloaded", only installed interactively. So I don't see how that helps people to package an extension globally, which is what this bug is about.
Comment by Eli Schwartz (eschwartz) - Monday, 01 February 2016, 06:44 GMT
Noticing we are collecting duplicates because of firefox-adblock-plus...

I believe the problem is that you are downloading the version hosted by Adblockplus.org -- in my original patch I switched to the AMO version. This is because Mozilla doesn't allow system installations of self-hosted (unlisted) addons (apparently neither the OS nor the extension is trusted enough).

The AMO copy passed "full" review, but developers sometimes like hosting their own unlisted copies, which is a problem for packaging. In order for *us* to use the XPI hosted away from AMO, they need to upload the AMO-blessed XPI (so why bother self-hosting, anyway?).
What confuses me is that the version downloaded by the current PKGBUILD doesn't have any signing data at all???


So I think it would be best for now to use the AMO url. Which unfortunately requires using the file number of that version of that addon (quite awkward), since Mozilla still hasn't figured out how to reliably offer specific versions of an addon...

Here is a patch for the latest version of Adblock Plus.
Comment by Pablo Lezaeta (Jristz) - Wednesday, 08 June 2016, 15:45 GMT
The bugs still exist and the duplicates still get created with every release.
https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/ that the adblock-plus signed plugin.

We can just update the packages and stop geting duplicates and adittional work?
Comment by Pablo Lezaeta (Jristz) - Wednesday, 20 July 2016, 04:54 GMT
Aparently no-script has ben solved, even the official page now point to firefox addons page now, anyone can confirm that for noscript?

also this bug still happend with ALL the other programs
Comment by Eli Schwartz (eschwartz) - Wednesday, 20 July 2016, 17:30 GMT
Noscript was a simple fix, because their website actually hosts a copy of the AMO release.
The only fix needed was to use the still-packed *.xpi instead of unzipping it (which caused permission issues with the signing data).
So it works fine now.

But the maintainer (Sergej Pupykin) only used part of my patch for Adblock Plus, which means, even though it is now properly installed like Noscript is, it still uses the self-signing by the Adblock Plus developers rather than the AMO.
Which means Firefox will complain and require you to turn off signature verification, and will eventually refuse it entirely...

...

The maintainer for the other two (speps) has not done anything for the two extensions he maintains. And Firebug is *still* flagged out of date.
He hasn't been very active recently though: https://www.archlinux.org/packages/?sort=-last_update&packager=speps
Comment by Chih-Hsuan Yen (yan12125) - Wednesday, 03 August 2016, 04:36 GMT
Firefox 48 in [testing] enforces signature verification. This ticket should now have priority medium or high.
Comment by Sven Karsten Greiner (SammysHP) - Friday, 05 August 2016, 14:19 GMT
What is the current state of this issue? Using FF 48 I am still able to disable signature verification via xpinstall.signatures.required=false.

 FS#45900  says that Arch will follow upstream and enforce the signature verification.
Comment by Chih-Hsuan Yen (yan12125) - Friday, 05 August 2016, 15:02 GMT
Great catch. I believe it's an Arch bug - submitted as  FS#50269 .
Comment by Shalygin Konstantin (k0ste) - Saturday, 06 August 2016, 05:02 GMT
Eli make Delete request for my package https://aur.archlinux.org/packages/firefox-extension-adblock-plus in AUR.
I create it because we can't contact with maintainer (Sergej Pupykin).
I think if Arch can not support extensions like this - should be dropped to AUR and take normal (signed) support. Otherwise 'bug' should be fixed, because package without signature for now useless.
Comment by Sergej Pupykin (sergej) - Saturday, 06 August 2016, 21:27 GMT
My packages should work now.
Comment by Eli Schwartz (eschwartz) - Sunday, 07 August 2016, 02:57 GMT
The fact that a package in the repos is useless, is not valid grounds for creating an AUR package. And "the maintainer isn't responding" is not valid grounds either, as far as I am aware.

Anyway, it is fixed now, thanks Sergej.
Comment by Pablo Lezaeta (Jristz) - Monday, 27 March 2017, 16:28 GMT
So far the status is:

firefox-adblock-plus: fixed
firefox-noscript: no idea
firefox-firebug: no idea
firefox-raismth: dropped to aur
arch-firefox-search: no idea... also not even follow the other name-style

Can someone confirm if the "no idea" work in they systems?
Comment by Eli Schwartz (eschwartz) - Tuesday, 01 August 2017, 23:47 GMT
  • Field changed: Severity (Low → High)
noscript works okay, they use the official signing data in their self-hosted release.

firebug is the only remaining holdout that still needs to be fixed.

Also, setting the severity to high because at this point missing signatures means the package simply won't work at all, under any circumstances.

...

speps hasn't really been active at all save for some brief activity on 2016-12-29 so I don't really know what is happening with this. Maybe we should just drop it to the AUR if we cannot find a maintainer to fix it... it has also had *numerous* releases since it was last packaged...
Comment by Connor Behan (connorbehan) - Wednesday, 02 August 2017, 01:26 GMT
According to Yen Chi Hsuan's post (which defended the closing of  FS#45900 ), there is a circumstance in which an addon without signatures will work: an Arch user installing nodejs-jpm to cancel out Mozilla's anti-feature. If this is no longer the case, then Arch will be useless to addon developers unless we re-open  FS#45900  and uncripple our package like we should've done all along.
Comment by David Runge (davezerave) - Monday, 04 December 2017, 22:27 GMT
I think this can be reassigned to @sergej and closed.
firefox-{adblock-plus,noscript} and arch-firefox-search work, the others have been deleted.

Loading...