Page 1 of 1
Global installation and extension signing
Posted: Fri Nov 27, 2015 11:26 am
by Andreas_H
Hello,
I used to install some firefox extensions at our site globally, i.e. by unpacking and placing them in a folder in /usr/lib/firefox-addons/extensions/<Extension-UUID>.
Since Firefox 40, I now get a warning that NoScript is not a signed extension, even though it should be. Not a problem until now, but it will become one when Mozilla decides to enforce extension signing.
When I install the same XPI in the user profile, everything is OK.
This does not happen with e.g. AdblockPlus, but it does happen with HTTPSEverywhere.
Any ideas what I could do?
Thanks,
Andreas
Re: Global installation and extension signing
Posted: Fri Nov 27, 2015 3:00 pm
by barbaz
NoScript should be signed. If you have any doubt about that, try download it from
AMO, where it will definitely be signed. If that doesn't help then you may have found a Firefox bug, you can file it on
https://bugzilla.mozilla.org/ (but please search there first to see if someone has already filed one). Please post the Bugzilla link here if you find or file a bug, thanks.
Re: Global installation and extension signing
Posted: Sat Nov 28, 2015 12:29 pm
by therube
I used to install some firefox extensions at our site globally, i.e. by unpacking and placing them in a folder in /usr/lib/firefox-addons/extensions/<Extension-UUID>.
Since Firefox 40, I now get a warning that NoScript is not a signed extension, even though it should be.
Confirmed.
NoScript should be signed.
It is, but that's not the issue.
Now why unpacking it, breaks it, I have no clue, & to me, it is unepected?
Note that in FF, global extensions go into instalDir/browser/extensions/, where in SeaMonkey we would still be in instalDir/extensions/ (though I didn't actually check that).
Also note that
NO changes can be made to any unpacked extension, or it will fail validation. (Actually no changes can be made to an extension - whether in xpi form, or whether unpacked. And NO means none what so ever - no addition, like a readme.txt where you've added a note to yourself, nor a change - of any sort, nor any deletion from the original signed files contents.)
Re: Global installation and extension signing
Posted: Mon Nov 30, 2015 11:22 am
by Andreas_H
therube wrote:I used to install some firefox extensions at our site globally, i.e. by unpacking and placing them in a folder in /usr/lib/firefox-addons/extensions/<Extension-UUID>.
Since Firefox 40, I now get a warning that NoScript is not a signed extension, even though it should be.
Confirmed.
NoScript should be signed.
It is, but that's not the issue.
Now why unpacking it, breaks it, I have no clue, & to me, it is unepected?
Strange thing is that it does not break with AdblockPlus. I tried a few other extensions, namely VideoDownloadHelper, but failed to find another one that works; all fail in the same way like noscript.
Note that in FF, global extensions go into instalDir/browser/extensions/, where in SeaMonkey we would still be in instalDir/extensions/ (though I didn't actually check that).
Actually, on Ubuntu, /usr/lib/firefox-addons/extensions and /usr/lib/firefox/browser/extensions are hard links to the same directory.
Also note that NO changes can be made to any unpacked extension, or it will fail validation. (Actually no changes can be made to an extension - whether in xpi form, or whether unpacked. And NO means none what so ever - no addition, like a readme.txt where you've added a note to yourself, nor a change - of any sort, nor any deletion from the original signed files contents.)
I know, that's the point of signing after all. But that's not the case here.
I might head over to mozilla support as well as to the ABP developers and ask if they have any information on that issue.
Re: Global installation and extension signing
Posted: Tue Dec 01, 2015 8:47 am
by Andreas_H
This is what I got from Jorge Villalobos:
Hello,
We had a problem with the signing system after the move to AWS (a couple
of weeks ago), and a number of add-on files were incorrectly signed.
They still install correctly in Firefox via the usual mechanism, but
won't work correctly if you try to install them from a global location.
I think that later this week we will run a script that correctly signs
(again) all of them, which should fix the problem.
Jorge
I don't know him, but mozilla pages say he's "the Add-ons Developer Relations Lead for Mozilla". So I'll take this as an "official" answer and wait a little...