Bug 802285 – www-client/firefox-90.0 does not support unsigned addons anymore

• Product: Gentoo Linux
• Status: UNCONFIRMED ---

[Description Andreas Fink 2021-07-15 13:19:35 UTC]

I emerged firefox-90.0 as always, but suddenly my own developed test addons are not accepted anymore. The option xpinstall.signatures.required is set to false, but it seems to be ignored in firefox-90 due to some changes that they did with the build system.
I looked a bit around the build system and found the environment variable  MOZ_REQUIRE_SIGNING.
First I tried setting it to the value 0, but the build system of firefox complained that this variable should not have any value. So I just exported the environment variable (via /etc/portage/env/moz_signing.conf, and adding it to package.env). 
Now I'm able to load unsigned addons again.
It seems counter-intuitive that when this environment variable is exported during build, then signing is not required. Could be even a bug in the firefox build system, where the environment variable should have a value (0 or 1).
Anyway, for the time being I have solved it locally, but it could be worth for other users to add this to the ebuild itself.

Reproducible: Always

[Comment 1 Thomas Deutschmann (RETIRED) 2021-07-15 14:34:29 UTC]

We are talking about https://bugzilla.mozilla.org/show_bug.cgi?id=1712633 which landed in v90. However, I tend to close this as WONTFIX:

We still set --with-unsigned-addon-scopes=apps,system which means the system administrator can install unsigned addons into locations only writable for system administrator. This is the way to go. Everything else will put users at risk which is why I tend to WONTFIX (you maybe still be able to workaround via package.env/EXTRA_CONF but this is nothing I'd like to expose to users in general).

[Comment 2 Andreas Fink 2021-07-15 15:50:40 UTC]

I can live with that.
I just tried putting my addons to /usr/lib64/firefox/browser/extensions, and indeed that works too. I was not aware that one can put extensions there. On a multi-user system this could be an issue, but I'm not affected by it, only one user here.

And you're right, that one can always work around as I mentioned also in my first bug report by exposing one environment variable to the build system.

[Comment 3 tt_1 2021-07-15 20:45:14 UTC]

so you copy the xpi files into /usr/lib64/firefox/browser/extensions , and then you install via about:addons?

[Comment 4 Andreas Fink 2021-07-16 04:24:56 UTC]

No you still cannot install it, even if it is located there, but Firefox would autoload them if you follow these steps:
1. copy the XPI file to /usr/lib64/firefox/browser/extensions
2. Make sure the file is owned by root (chown root:root my_file.xpi)
3. Rename the file to the right filename convention. Here I am absolutely unsure what kind of filenames Firefox expects, but what worked for me is to rename them to EXTENSION_ID.xpi, where the extension id is in the manifest.json under the key applications/gecko/id.

Not sure if step 2 is required, I did not try without it.
Definitely step 3 is required, not every name will be autoloaded. But I do not know what the rules for autoloading are, I just gave the same magic filename as firefox did in my ~/mozilla/firefox/profile_dir/extensions/magic_filename.xpi

By default when the addons are auto-loaded they will be disabled, so you still need to enable them in about:addons.

[Comment 5 tt_1 2021-08-04 10:50:19 UTC]

fedora tries to bypass via

--with-unsigned-addon-scopes=app,system

you can inject it with EXTRA_ECONF="" via /etc/portage/env/

I haven't tested it since I don't have a personal use case, so please be carefull

[Comment 6 Thomas Deutschmann (RETIRED) 2021-08-04 14:53:23 UTC]

(In reply to tt_1 from comment #5)
> fedora tries to bypass via
> 
> --with-unsigned-addon-scopes=app,system
> 
> you can inject it with EXTRA_ECONF="" via /etc/portage/env/
> 
> I haven't tested it since I don't have a personal use case, so please be
> carefull

Note that we do exactly the same, https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/firefox/firefox-90.0.2.ebuild?id=074f035c1c83bc31e27296d2a77380c9d8d21ba5#n631 -- see comment #1.