1047239 - (signed-addons) Add-on signing revamp

Status: RESOLVED FIXED

(Firefox :: Security, defect)

Description

[Daniel Veditz [:dveditz]]

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

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking this as a feature to help with tracking, QA, and general awareness of active/upcoming work.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 40 since this is aimed at release in Firefox 40.

Comment 4

[znmeb]

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?

Comment 5

[John Doe]

Go to "about:config".
Search for "xpinstall.signatures.required".
Set it to "false".

Comment 6

[Daniel Fisher]

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.

Comment 7

[John Doe]

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.

Comment 8

[Daniel Fisher]

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!

Comment 9

[Dave Townsend [:mossop]]

Please file new bugs if you are seeing issues with add-ons in Firefox 40. This is just a tracking bug.

Comment 10

[Alex Heusingfeld]

@Dave I couldn't find "xpinstall.signatures.required" being documented anywhere here [1] 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.

[1] https://wiki.mozilla.org/Addons/Extension_Signing

Comment 11

[alex_mayorga]

¡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!

Comment 12

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(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.

Comment 13

[Benoit Girard (:BenWa)]

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.

Comment 14

[Dave Townsend [:mossop]]

(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.

Comment 15

[(no longer active)]

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?

Comment 16

[Dave Townsend [:mossop]]

(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.

Comment 17

[Kris Maglione [:kmag]]

(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.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Stop tracking as it is a meta bug and it is not really actionable.

Comment 19

[help_be]

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

Comment 20

[Dave Townsend [:mossop]]

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

Comment 21

[Chris G]

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.

Comment 22

[Dave Garrett]

(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.

Comment 23

[HttpWatch]

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

Comment 24

[Stefan Kanthak]

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.

Comment 25

[HttpWatch]

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.

Comment 26

[Dave Townsend [:mossop]]

(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

Comment 27

[u279673]

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.

Comment 28

[Dave Townsend [:mossop]]

(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.

Comment 29

[LafinJack]

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.

Comment 30

[Dave Townsend [:mossop]]

(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

Comment 31

[Anonymous]

This is egregiously fascist and duplicitous of you, Mozilla. 

While I'm well aware of Hanlon's razor, it doesn't apply here, because it's simply impossible that you are that stupid and short-sighted. You're not that stupid and short-sighted. You know perfectly well that this new rule isn't ever going to make a blind monkey's bit of difference to Firefox security. Any malicious software in a position to install itself into the browser is also in a position to wreak all manor of other catastrophically compromising changes to it, or simply to replace the browser with a custom build.

The only effect of mandatory add-on signing is as a means of control and surveillance over custom add-ons that people want to use. It's incredibly inconvenient and I just don't know what I'm going to do about it once ESR 52 drops later this year. Using the Developer edition is not an option, since I need the ESR edition.

I so desperately wish there were a better browser than Firefox, one that still respects freedom and privacy out the box, without requiring an ever-growing list of intricate about:config hacks and add-ons to restore some semblance of user control. Very unfortunately, you're the best, and that means that whet you turn fascist, everyone loses. It's awful that you're forcing this through.

Comment 32

[Anonymous]

You all know very well that enforcing this egregiously dictatorial restriction won't improve Firefox security by the tiniest bit of a squit of a dot of a jot. By the time an add-on is in a position to install itself secretly it's too late: it can already perform other unlimited compromising changes to the user's browser or computer. You make it a little harder for malicious add-on developers, sure, because they may have to create a custom compilation of the entire browser, for instance, but you don't actually stop them from doing anything they can't already do. How do you possibly justify this APPALLING rule? Its *****ONLY***** practical effect is to control and surveil end users. Otherwise you would be willing to let the user disable the rule.

Comment 33

[Jorge Villalobos [:jorgev] (he/him)]

Closing this meta bug since most dependencies have been closed and we're not really tracking it.