FireFox 90 unable to install unsigned webextensions

Bug #1937343 reported by Lorem Daijoh
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
firefox (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Ubuntu 18.04
FireFox 90.0+build1-0ubuntu0.18.04.1

Steps:

    - Set xpinstall.signatures.required to FALSE in about:config

    - Attempt to install UNSIGNED extension from file (Install Add-on From File...) in about:addons

Expected:

    - FireFox warns about unverified add-on but ALLOWS installation.

Actual result:

    - FireFox prevents the installation.

Installing unsigned extensions used to work on all FireFox versions before 90.

Related question https://answers.launchpad.net/ubuntu/+question/698053

There appears to be at least one other affected person https://old.reddit.com/r/firefox/comments/ootacl/unverified_addon_not_working_anymore_since/

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
Lorem Daijoh (lorem-daijoh) wrote :

Unfortunately it seems that the latest builds still have this bug. Tested with:

91.0+build1-0ubuntu1 (Impish)
90.0.2+build1-0ubuntu0.18.04.1

Another unhappy user https://discourse.mozilla.org/t/just-log-in-to-say-farewell-to-firefox-after-about-20-years-bye-ff-extension/83463

Pingin Olivier Tilloy for some insight, please!

Revision history for this message
Michael Kaply (mkaply) wrote :

The fact that unsigned extensions worked on Ubuntu release (or any Linux release) was a bug. It was fixed here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1712633

If you want to use unsigned extensions, you'll need to use developer edition, nightly, or ESR.

Revision history for this message
Lorem Daijoh (lorem-daijoh) wrote :

Oh that is sad information indeed, but thank you!

Unfortunately none of the other versions can be found in the Ubuntu repositories, which means no updates through the regular channel and no distribution specific patches.

And having to submit your personal extensions for review is just not OK!

As a workaround I have started using a script to modify the omni.ja to set the MOZ_REQUIRE_SIGNING to false. It's a pain but I pray they do not "fix" that too. It would be even a bigger pain to have to build Firefox from scratch each time!

I wonder if there is enough like minded persons within Ubuntu users, so that the MOZ_REQUIRE_SIGNING flag could be ACTUALLY set to false on Ubuntu builds. Where should one suggest this?

Revision history for this message
Olivier Tilloy (osomon) wrote :

Thanks for the reference to the upstream bug Michael.

Here is some comprehensive documentation: https://wiki.mozilla.org/Add-ons/Extension_Signing (see the Timeline section, the preference that you mention was deprecated in Firefox 48, released 5 years ago).

Revision history for this message
Olivier Tilloy (osomon) wrote :

MOZ_REQUIRE_SIGNING is a security measure to prevent users from running unsigned (and potentially damaging) extensions, while I understand your use case it is not reasonable to suggest turning it off by default for all Ubuntu users.

Changed in firefox (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Lorem Daijoh (lorem-daijoh) wrote :

It's not like setting MOZ_REQUIRE_SIGNING to false would allow running unsigned extensions outright. There is also about:config setting xpinstall.signatures.required, that is true by default and needs to be set false by the user before unsigned extensions can be installed.

The about:config setting is behind a grave warning about security ramifications if tampered with. Still, if user attempts to install unsigned extension, they are met with another warning dialog and even after accepting that the extension is marked with big warning label about being unverified in the add-ons manager. There is no way user could install unsigned extension by mistake.

And indeed this "security hole" has been around for the last 5 years, yet there appears to be no related exploits. The bug certainly does not mention of any.

As mentioned, the official way around this is to install one of the Firefox versions that has MOZ_REQUIRE_SIGNING set to false on default. On Windows that might be reasonable. However, none of these are available in Ubuntus repositories. It is not big hassle to install them from Mozillas own sources, but those installations will be user specific, are not covered by the usual update system and are missing any distribution specific patches. The options left for Ubuntu users (or Linux distro users in general) are not reasonable.

So that's my take on the reasonability of this. I was really hoping more balanced approach could be taken.

Revision history for this message
Wang Ling (letrois) wrote :

Very much agree!
For the very reason, I abandoned Firefox after 20 years of loyal support, and finally embrassed Chrome just this week.
I do need my personal extensions. I do not want to submit my personal extensions for signature. I do not even need to pack them.
In chrome I can install unpacked extensions in develop mode and keep using them that way, while Firefox discards loaded unpacked extension after each session. I'm not sure if this feature will be changed in the future in chrome. So, the fact that I can not use my personal extension in FF is still kinda pain in my ass.
As long as there is a workaround, like patching omni.jar, this "stricter meassure" makes no difference from before, thus I would say "pointless".
Anyway, I'm starting to appreciate Mozilla turning me into a "majority" chrome user. Good luck to Firefox!

Revision history for this message
CGar (cgarz) wrote :

I already have a mother to nanny me. It's disconcerting that Firefox thinks it's okay to try and muscle into that role.

The whole point of Firefox for many is the freedom to customize and set things how they like.

But who cares about that. All that matters now is the obsessive overbearing coddling of the user and the removal of all the wonderful sharp edges in the name of sEecOoOrItY.

Revision history for this message
KOLANICH (kolanich) wrote :
Revision history for this message
KOLANICH (kolanich) wrote :

>MOZ_REQUIRE_SIGNING is a security measure to prevent users from running unsigned (and potentially damaging) extensions, while I understand your use case it is not reasonable to suggest turning it off by default for all Ubuntu users.

If I remember right, it was a consensus that the policy of enforcement of Mozilla policy applies only to builds for Linux built by Mozilla itself, and distros were free to not to enforce Mozilla policy. It may make sense to rename the package back into iceweasel and not to be bound by Mozilla harmful policy. The usage of the name "Firefox" is less valuable than the ability to customize the browser as we wish. It is absolutely humilating that there is a need to get Mozilla approval in order to do on our computers what we want and need to do.

Revision history for this message
Olivier Tilloy (osomon) wrote :

To follow up on Michael Kaply's comment (#3), using the firefox snap one can install Firefox from the beta channel, nightly, ESR, or even all of them in parallel. See https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1515125/comments/3 for details.

Revision history for this message
KOLANICH (kolanich) wrote :

Please stop promoting snap. I and a lot of people are not going to use it. Snap is not unix-wayish, it is Windows-bloated-wayish. A big step back and complete garbage. The same way flatpak and appimage and docker-container-as-a-unit-of-software are.

I have almost created a script that patches the binary installation in order to workaround Mozilla's sabotage (I have never tested that the method works though, but I guess it should). When finished, I gonna create a binary package with triggers to patch firefox on installation.

The only missing ingridient is the python library for editing zip archive in place (because I don't want to unpack and repack the whole archive just to patch 1 small JS file). Since it is a complex task, I just followed the way of creating a ctypes-based bindings for a C library for manipulating zip archives.

It is here https://github.com/KOLANICH-libs/libzip.py in an unfinished unworking state (well, ctypes part works, but we need to wrap it properly in an interface similar to ZipArchive to be a kinda drop-in replacement, or maybe even promote it into the stdlib). I currently have no time to work on it. Help is welcome.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.