How to find out if a Firefox add-on is signed
How do you know whether a Firefox add-on is signed or not? And what does it mean if it is signed?
One could say that you find out as soon as you try to install the add-on in a recent version of Firefox and that is certainly true, but it may sometimes be useful to know in advance.
For instance, how many of the add-ons that you have installed will be blocked by Firefox when add-on signing is enforced? Or, can you distribute the add-on that you found on a third-party site, or will Firefox refuse to install it on systems you want it deployed on?
Firefox indicates whether add-ons are signed or not. If you open the add-ons manager of the browser by loading about:addons in the address bar for instance, you will notice that unsigned add-ons are highlighted in it.
A yellow exclamation mark and warning "could not be verified.. proceed with caution" is displayed above the add-on name in the add-ons manager.
But how can you find out about the signing status of add-ons that you have not installed?
There is only one rule of thumb available right now, and that is that all recent versions of add-ons listed on Mozilla's AMO website are signed.
While that is helpful at times, it won't help you if you want to install or distribute an add-on offered on a third-party site. You could install that in Firefox and see if you get an error message trying to do so or not.
If you run Firefox Developer Edition or Nightly, you can flip a switch to allow the installation of unsigned add-ons in the browser, whereas Firefox Stable and Beta will refuse to install those add-ons right away once the enforcement version of the browser has been reached (Mozilla plans to enforce this when Firefox 44 is released to the stable channel).
There is another option, one that does not require that you run Firefox at all. You do need the .xpi file of the extension for that, or the extracted contents of the .xpi file.
Zip programs like Bandizip can unzip Firefox add-on files with the .xpi extension.
- Extract the .xpi file using a zip program that supports the operation.
- Open the META-INF folder in the root directory of the extracted package.
If you find a zigbert.rsa file in the META-INF directory, the add-on is signed. If you don't, then it is not.
Note: I have checked this with a good dozen signed and unsigned add-ons and it matched the assumption. I cannot vouch however that this is a 100% surefire way of telling if an add-on is signed or not. For now though, it seems to be an accurate method.
Now You: Are you affected by the upcoming add-on signing policy?
All my addons are signed. However, one of them I modified (just a very small change in the code due to some deprecation to get Extension List Dumper working again, it was about a year ago – the fix is actually posted on the extension’s AMO page’s comments) – so it will be interesting to see what happens to that. If FF doesn’t pick up on it, then it would be a pretty useless shitty implementation of signing :)
The META-INF folder inside the signed zipped .xpi file indeed, and it’s a true locker as well. I had tried to modify a signed add-on by unzipping it, modifying lust one little thing, re-zipping it and giving it a go for install : add-on was no longer considered signed. Normal, wasn’t too surprised but still, frustrating!
Damned. Once truly active (unless Mozilla proves to be wiser) this “stuff is gonna drive me nuts” :) Already hate it even if I know it’s as motivated by good reasons as poorly carried out this time.
Read my comment above. I updated the add-on (had to be updated due to signing). The addon is broken, needs a slight code change, but I guess the author vanished years ago. It’s a very simple fix.
So, the addon was updated to the signed version. This then broke the extension, as in it wouldn’t work. I edited the code in the xpi (same as you, unzip, edit, zip, rename etc) – bearing in mind that this was in my extensions directory – not some xpi file to use for install. Restarted FF, and the addon was now working as expected – i.e it’s still in addons, it’s not blocked, it’s marked as signed. It’s listed as – Extension List Dumper 184.108.40.206-signed. So there .. security bypassed (well, at least I could do it when they introduced the start of the “-signed” updates – was that 6 months or more ago?).
Pants, when I wrote my comment above (Tom Hawack December 1, 2015 at 2:25 pm) yours (Pants December 1, 2015 at 2:08 pm) wasn’t published yet : I wrote it independently of yours.
Now, reading your experience is stunning. As I understand it, you haven’t edited the xpi file in order to re-install it but you’ve edited it right in your Firefox’ profile / extensions folder. Is this correct? If so, this is brand news for me and at the same time, as you state it “So there .. security bypassed”. Amazing.
P.S. Just read the comment on the add-on’s AMO page. Indeed.
Tom – yeah, I meant read my comment above (to get the info so I don’t have to type it again). I know comments take time to come thru :)
Yes, to clarify, I edited the code directly in my FF profile AFTER installation/update.
For an extension XPI file to be signed, its first ZIP entry should be “META-INF/zigbert.rsa”. Otherwise, the extension should not be considered signed.
See https://developer.mozilla.org/en-US/docs/Signing_a_XPI , for more information.
Unfortunately, popular ZIP software for Windows do not seem to provide a way to easily view the ZIP archive’s member file order.
Thanks Q, I have updated the guide accordingly. Great find.
I do not remember this page’s original article content well enough. I believe that your update was:
“If you find a zigbert.rsa file in the root directory, the add-on is signed. If you don’t, then it is not.”
The statement is incorrect. The “zigbert.rsa” file should be in the ” META-INF” directory (which itself is at root). Also, in the the XPI (ZIP) file, the “META-INF/zigbert.rsa” member file MUST be first in the ZIP archive.
Files are aggregated to a ZIP archive in order (whatever that may be); the archiving software might use its own order scheme to add files to a ZIP archive. An example is 7-Zip, which adds files to ZIP archive in alphabetical order.
The archiving software, WinRAR, does appear to be able to generate a report that shows member file data in original order. To see it, one should select Generate report from the Tools menu and have sort order set to “Original order”.
Right, bad copy and paste job. Corrected this ;)