Closed Bug 1047239 (signed-addons) Opened 5 years ago Closed 4 months ago
Add-on signing revamp
As discussed in mozilla.addons.user-experience we plan to require that Firefox add-ons be signed with mozilla-issued certificates to help get a handle on the proliferation of malicious and harmful add-ons. An overview of the plan as discussed is at https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit?pli=1
Marking this as a feature to help with tracking, QA, and general awareness of active/upcoming work.
The web site https://wiki.mozilla.org/Addons/Extension_Signing says, "The Developer Edition and Nightly versions of Firefox will have a setting to disable signature checks." I just got Developer Edition 40.0a2 (2015-05-16) (Fedora Linux 64-bit) and I can't find this setting. I have an add-on that no longer works (TableTools2) as a result. Where is this setting?
Go to "about:config". Search for "xpinstall.signatures.required". Set it to "false".
I have installed dev edition 40.0a2 (2015-05-18). I've set "xpinstall.signatures.required" to "false" in "about:config". The "Settings" | "AddOns" show I have JSONView installed. When I browse to http://jsonview.com/example.json its obvious to see the add in is not active.
Seems to be working fine for me on the example with the latest version and a fresh profile. A couple of things you should try: Make sure it is actually enabled. Check what does it say in the add-on manager - do you see a "Disable" button? Do you have multi-processing enabled? Go to Options > General, look for "Enable multi-process Firefox Developer Edition" and disable it. Multi-processing seems to break the add-on for me. See if any other add-on is conflicting with it - try disabling all the other add-ons and check if it works.
I can see the "Disable" button. I disabled all. Restarted. Enabled "JSONView". Restarted. Opened http://jsonview.com/example.json. Same behavior. I disabled "Enable multi-process Firefox Developer Edition" - Now it works like expected. THANKS MUCH!
Please file new bugs if you are seeing issues with add-ons in Firefox 40. This is just a tracking bug.
@Dave I couldn't find "xpinstall.signatures.required" being documented anywhere here  or on the pages it links to, is this on purpose? Just FYI I came here searching for a cure to the same problem as Daniel: enabling "Enable multi-process Firefox Developer Edition" seems to make the value of "xpinstall.signatures.required" indifferent (running Firefox Dev Edition 40.0a2) and sort of disables all(!!) my addons. I opened bug 1167524 for this.  https://wiki.mozilla.org/Addons/Extension_Signing
¡Hola Daniel! Just noticed a few Mozilla own add-ons that are not signed: - ADB Helper 0.7.4 https://github.com/mozilla/adbhelper - Firefox OS 2.0 Simulator 2.0.20140918 https://github.com/mykmelez - Gecko Profiler 1.10.17 https://github.com/bgirard/Gecko-Profiler-Addon Are you aware of these? Else, what's the proper way to track them? ¡Gracias!
(In reply to alex_mayorga from comment #11) > - ADB Helper 0.7.4 https://github.com/mozilla/adbhelper > - Firefox OS 2.0 Simulator 2.0.20140918 https://github.com/mykmelez The DevTools team is working on signing these and a few others in bug 1162727. > - Gecko Profiler 1.10.17 https://github.com/bgirard/Gecko-Profiler-Addon I have not heard of an effort to get this one signed, maybe best to file a bug. Since it's aimed at browser developers, they may choose to ignore the singing requirement for this one since Nightly will allow unsigned add-ons.
Flags: needinfo?(dveditz) → needinfo?(bgirard)
Is there a question? The gecko profiler add-on is targeted at profiling nightly builds. This means that we have to support nightly platform changes in lockstep with add-on releases. Waiting for an add-on process is a no-go for our use case.
(In reply to Benoit Girard (:BenWa) from comment #13) > Is there a question? > > The gecko profiler add-on is targeted at profiling nightly builds. This > means that we have to support nightly platform changes in lockstep with > add-on releases. Waiting for an add-on process is a no-go for our use case. Nightly won't allow unsigned add-ons to install by default so users would have to disable the setting globally to be able to install your add-on if it is unsigned.
How do we sign this add-on without submitting it to AMO and being subjected to waiting multiple weeks every time we update the extension?
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #15) > How do we sign this add-on without submitting it to AMO and being subjected > to waiting multiple weeks every time we update the extension? Talk with the AMO team about what your options are, see bug 1162727 comment 11.
(In reply to Dave Townsend [:mossop] from comment #14) > Nightly won't allow unsigned add-ons to install by default so users would > have to disable the setting globally to be able to install your add-on if it > is unsigned. I'm not sure this is actually an issue. The two groups of people who are likely to be interested in Gecko Profiler are add-on developers and browser developers. Add-on developers will certainly be turning off the signing requirement, and I'd largely be expecting browser developers to do the same. It would be nice to have signed versions that support release channels, and unsigned versions that target nightlies.
Hello, I was trying to submit a new add-on for getting signed by Mozilla (beta version). Unfortunately, this process not work good for me. After "select file", the file loaded and the validation process continue more than a 3 hours (screenshot attached). The process to upload the add-on to store (not as beta version) works fine. What should I need to do? Avi
This is a tracking bug and not for user support. Please ask support questions in the mailing list: https://lists.mozilla.org/listinfo/addons-user-experience
Thank you for disabling an add-on I bodged together on my own to disable tabs. So how can I get the thing signed since I have no intention or desire to release it? I made it for my own purposes, nobody else's. I took the Tabkiller add-on, and I took it apart, changed a value and then put it back together. Which by the way was incredibly difficult and took me a full day to do given I don't know coding from sh*t. And by god it worked. Every time a "new tab" opened, it became a new window. I just don't want my Firefox to use tabs. That's all I want. Now it's deactivated because "OOOH scary- no signature." Given I have almost no add-ons to begin with is completely a waste of my time to have this kind of protection. So you have managed to screw over a user because they dared to do something themselves. My coding friends and they talk about the fact that Firefox has no "sandboxing" like "all the other browsers have" all the time like it's a big deal... maybe you should work on that instead of hauling out stuff like this? And yes... I consider this to be a bug since it makes my usage of Firefox difficult, and I already have options that I can turn to. Chrome is totally kicking Firefox's ass but I hate Google so I have avoided it... but if I have to go there, I won't be coming back. Allow me to disable this feature please. Just tell me where in the about:config I need to go to turn it off. If the disable of that feature is in there, 99% of people will never know it.
(In reply to Chris G from comment #21) Addon signing is for release and beta builds only. If you're developing something yourself, use a developer build: https://www.mozilla.org/en-US/firefox/channel/#developer There is not and will not be a switch to disable addon signature requirements in the release or beta builds. If there was, malware would just turn it off. > My coding friends and they talk about the fact that Firefox has no > "sandboxing" like "all the other browsers have" all the time like it's a big > deal... maybe you should work on that instead of hauling out stuff like this? Addon sandboxing and mandatory AMO addon signing both deal with the same issue of making sure users don't run addons that break things. Sandboxing attempts to limit addon capability automatically and AMO addon signing limits addons by requiring automated and human review of all code before letting users run it. Addons can also be uploaded to AMO (addons.mozilla.org) for review and signing without publishing. If it's just for you, though, just use a build that doesn't require signatures.
We ship a binary extension as part of our Windows application and I have a few questions about how the new signing process would be applied to it. The extension is installed by our application setup program and places the following files in a subdirectory under the application folder: chrome.manifest install.rdf chrome/myextension.jar components/myextension.xpt components/myextension.dll The add-on is installed in Firefox using a registry key and the user is prompted to enable or disable the extension by the normal process. My questions are as follows: 1) How would we submit the extension for review? Could we submit the whole application or would the extension have to be repackaged in some other way. 2) The extension is Windows only. Would this cause a problem? 3) What file(s) would actually get signed? We don't use an XPI as the extension files are installed in a sub-directory
Signing the XPI alone is NOT enough, if/as long as add-ons are installed in user-writable and therefore unsafe directories, where the unpacked files can be tampered. EITHER allow installation of add-ons only in the installation directory of the application (on Windows %ProgramFiles%, on Linux /bin/...) where the unpacked files are protected agains tampering since only administrators/root can write there, OR sign all files and check their signatures before they are loaded/executed/interpreted/opened. The right solution is but to allow installation only in safe locations where users can't modify them.
Stefan, Thanks for your response. I hadn't seen this blog post about the removal of binary extension support in Firefox 41: https://blog.mozilla.org/addons/2015/05/04/dropping-support-for-binary-components/ Unfortunately, that means HttpWatch will drop support for future versions of Firefox as it is not viable to port the whole extension to JS/XUL or to use js_ctypes.
(In reply to HttpWatch from comment #23) In general please take support questions like these to the newsgroups where most of this has already been answered. > 1) How would we submit the extension for review? Could we submit the whole > application or would the extension have to be repackaged in some other way. Submit the extension as an XPI file (just a zip including all your extension's files). Once you have a signed XPI you can extract its contents (we add signature files into it) and ship those. > 2) The extension is Windows only. Would this cause a problem? No > 3) What file(s) would actually get signed? We don't use an XPI as the > extension files are installed in a sub-directory See above
Why the beta version? Plenty of times I've had addons non-functional for a few days until the developer catches up. Right now my most important addon, Vimperator, has been completely broken for a week, with the developer promising a fix over the weekend. I can understand doing this with the stable and ESR, but the beta? Why? The next time a crucial addon fails to work for more than a few days I downgrade to stable and you lose a bug reporting beta user until the addon is fixed.
(In reply to Dan Q (RedBlade7) from comment #27) > Why the beta version? Plenty of times I've had addons non-functional for a > few days until the developer catches up. Right now my most important addon, > Vimperator, has been completely broken for a week, with the developer > promising a fix over the weekend. I can understand doing this with the > stable and ESR, but the beta? Why? The next time a crucial addon fails to > work for more than a few days I downgrade to stable and you lose a bug > reporting beta user until the addon is fixed. Beta's are intended to be, to all intents an purposes, identical to what we would ship. They should have the same branding, configuration, everything to what would go in release. Disabling a feature in beta would mean that feature went untested before it hit the release population.
Current local 41b (no other extended version/build info is displayed anywhere) for Android has this enabled. The about:config setting is already set to false. Switching to true (i.e. if the setting was implemented backwards) does nothing. Switching back to false (i.e. if the initial setting was acting as true but displaying as false) does nothing.
(In reply to LafinJack from comment #29) > Current local 41b (no other extended version/build info is displayed > anywhere) for Android has this enabled. The about:config setting is already > set to false. Switching to true (i.e. if the setting was implemented > backwards) does nothing. Switching back to false (i.e. if the initial > setting was acting as true but displaying as false) does nothing. Please file a new bug for that so we can investigate and track it
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.