Firefox configurable #58195

xaverdh · 2019-03-24T08:08:15Z

Motivation for this change

This is the same as #57554, except for the implementation, which differs. This pull request patches the browser to take the configuration directories from environment variables, which can then be set in e.g. the wrapper (the original pr did some symlink trickery).

Things done

I tested this with firefox on NixOS, but I did not, and probably cannot test it on darwin.
Also as is, this also patches all the variants of firefox, we may want to limit that to just firefox?
The tor-browser-bundle in particular already has some code that deals with AutoConfig in its derivation, I am not sure how this fits together. I pushed changes to only patch firefox proper.

andir

Thank you for working on this! 👍

Only had a brief look so far.

I do not like the fact that we can not remove extensions and that (as you wrote) is still a lot in flux regarding that. Is it maybe a bit too early to add the extensions feature?

I really like the fact that we will be able to declare policies (finally). Since it allows users to disable things like DNS over HTTPs per default etc…

Every FireFox release we have to update ~3 branches with at least 2 versions at any time. It would be great if the patches could be upstreamed to reduce the maintenance on them. Very often there is some subtile reformatting/restyling going on that breaks the patches.

xaverdh · 2019-03-24T10:57:56Z

I already dropped the extensions option that was part of the original pr. The docs still mention, that this can be used for extensions, but I attempted to phrase it very carefully (I can drop it completely if you insist).
Yes, I made no attempt at communicating with upstream so far, because my general impression is, that the mozilla devs (at least some of them) are usually not interested in making anything user/distro configurable. Usually they say its a security risk for some reason or another.
What do you suggest is most promising the way to contact them? I have a feeling that just creating a bugzilla report will achieve nothing :-/

7c6f434c · 2019-03-24T11:15:16Z

I would seek advice about communicating with Mozilla from @nbp

With Mozilla there is always a dual question — are the changes large enough to require asking again about official branding…

andir · 2019-03-24T16:23:45Z

I agree with @7c6f434c as I had the same concerns but didn't want to raise them as such just yet. It feels like it is a point of no return (even for trivial changes). Once that topic is on the table we have no way back ;-)

In any way, if we decide that this is a desirable feature we can still include it whenever the official branding is disabled.

7c6f434c · 2019-03-24T19:49:21Z

Not sure if negotiating a command-line option with upstream is easier.

andir · 2019-03-25T14:38:04Z

@xaverdh you might want to adjsut the commit messages to fit our guidelines.

xaverdh · 2019-03-25T15:26:50Z

@xaverdh you might want to adjsut the commit messages to fit our guidelines.

Yes, while doing that, should I squash everything or leave the commits separate?

infinisil · 2019-03-27T02:43:15Z

pkgs/applications/networking/browsers/firefox/wrapper.nix

+      policiesJson = builtins.toFile "policies.json"
+        (builtins.toJSON enterprisePolicies);
+
+      mozillaCfg = builtins.toFile "mozilla.cfg" ''


You should use pkgs.writeText for these, builtins.toFile is an evaluation time thing, which means it can't depend on any derivations, which might be wanted.

Right, I will change that.

infinisil · 2019-03-27T02:43:51Z

pkgs/applications/networking/browsers/firefox/wrapper.nix

@@ -81,6 +83,25 @@ let
            ++ lib.optional (config.pulseaudio or true) libpulseaudio;
      gtk_modules = [ libcanberra-gtk2 ];

+      enterprisePolicies = {


Why is this named enterprisePolicies?

Because that's what upstream calls it.

infinisil · 2019-03-27T02:44:47Z

pkgs/applications/networking/browsers/firefox/wrapper.nix

+      firefox-user-config = runCommand "firefox-user-config" {} ''
+        mkdir $out
+        cat > "$out/policies.json" < ${policiesJson}
+        cat > "$out/mozilla.cfg" < ${mozillaCfg}


Why not just cp ${policiesJson} $out/policies.json?

For no reason in particular. The two are mostly interchangeable.
If cp is preferred over cat, I can change it.
Depending on your viewpoint cp is the more complex tool I guess.

I think we should use cp to copy files :)

infinisil · 2019-03-27T02:49:53Z

pkgs/applications/networking/browsers/firefox/common.nix

+    mkdir -p "$out/lib/firefox/defaults/pref"
+    cat > "$out/lib/firefox/defaults/pref/autoconfig.js" <<EOF
+      pref("general.config.filename", "mozilla.cfg");
+      pref("general.config.obscure_value", 0);


What's the point of this? Why these two options and why use autoconfig when this file won't ever change anyways (read-only nix store)?

I think «prepare» is in terms of Nixpkgs-time, i.e. check that autoconfig works so that another change can actually introduce customisable autoconfig.

That's the crazy way mozillas AutoConfig system works. The actual configuration file is added in the wrapper, but this file (autoconfig.js) has to be there in order for the AutoConfig machinery to do anything at all. Without it, firefox will just ignore the configuration file proper.
The first line tells firefox, that the name of the real configuration file is mozilla.cfg. This also has to be there, because some (enterprise) parties used it as a "lock down" mechanism, to prevent users from renaming it. In the same spirit, the configuration file (mozilla.cfg) is by default expected to be obfuscated by byte shifting. So the second line tells firefox that we use an non-obfuscated config file.
All of this is documented here.

Oh wow, can you add this link to the code?

This adds an option installAutoConfig, which installs an autoconfig.js file in the appropriate subdirectory of the firefox runtime.

This adds patches to make the paths where firefox looks for the enterprise policies file (policies.json) and the autoconfig file (mozilla.cfg) configurable by setting the environment variables MOZ_POLICIES_DIR and MOZ_AUTOCONFIG_DIR respectively.

This uses MOZ_POLICIES_DIR and MOZ_AUTOCONFIG_DIR to point firefox to the users configuration.

This documents configuring firefox by passing options to the wrapper.

nbp · 2019-03-29T19:50:15Z

I would have suggested to upstream these patches before accepting this changes in Nixpkgs. Unfortunately I do not think these patches would be accepted upstream because they are adding the option for a user to work-around the enterprise settings, using environment variables, which are meant to be controlled by the administrator.

Knowing that these extra patches are unlikely to make it upstream, this implies that firefox-wrappers will not work as expected with pre-built versions of Firefox.

Thus I wonder, is there any reason why our firefox-wrapper does not clone the content of the firefox directory and wrap the copied binary, in which case you can easily place the mozilla.cfg file and distribution/policies.json at the top-level of the firefox install directory.

No?

Apart from these remarks, I love the intent and I wanted these features for a while!

xaverdh · 2019-03-29T22:40:41Z

Thus I wonder, is there any reason why our firefox-wrapper does not clone the content of the firefox directory and wrap the copied binary, in which case you can easily place the mozilla.cfg file and distribution/policies.json at the top-level of the firefox install directory.

That's essentially what the original pull request did (#57554). Actually it used symlinks mostly instead of copying.

xaverdh · 2019-03-29T22:50:32Z

I would have suggested to upstream these patches before accepting this changes in Nixpkgs. Unfortunately I do not think these patches would be accepted upstream because they are adding the option for a user to work-around the enterprise settings, using environment variables, which are meant to be controlled by the administrator.

I personally don't really understand the issue, since a user can always execute his own private version of firefox, or copy the entire runtime and replace the config file, or rewrite parts of the binary before executing it.
Either way, do you think that hiding these changes behind a compile time flag might be an option to get the changes upstream?

infinisil · 2019-04-01T00:16:59Z

So, what's the better way out of the two? I'm a bit confused as to why there are two PR's that seemingly do the same.

Edit: Ah you mention that in the description of this PR, already forgot :)

So, I personally prefer this way, it seems less hacky.

nbp · 2019-04-01T10:13:33Z

I would have suggested to upstream these patches before accepting this changes in Nixpkgs. Unfortunately I do not think these patches would be accepted upstream because they are adding the option for a user to work-around the enterprise settings, using environment variables, which are meant to be controlled by the administrator.

I personally don't really understand the issue, since a user can always execute his own private version of firefox, or copy the entire runtime and replace the config file, or rewrite parts of the binary before executing it.

This feature is meant for enterprise installation, where users might not have as much freedom. This can also be the case on NixOS, if you forbid execution flags on partitions others than /nix/store and the setuid-wrapper directory. (which I should write a module for one day …)

Either way, do you think that hiding these changes behind a compile time flag might be an option to get the changes upstream?

Yes, but it would not be enabled for the binary distribution of Firefox. Which implies that this configuration toggle is at the mercy of anyone who might want to do a bit of clean-ups.

I will give look later at the previous PR using external patching mechanism.

andir · 2019-04-24T21:59:56Z

I just came across this Bugzilla Entry: https://bugzilla.mozilla.org/show_bug.cgi?id=1170092

It has a patch (https://src.fedoraproject.org/rpms/firefox/blob/master/f/mozilla-1170092.patch) that allows putting configuration into /etc/firefox. This might not be entirely what we want but it is a start. Fedora has been shipping this for a few years (and still kept the branding on…).

teto · 2019-07-17T05:47:20Z

The feature is very desirable. The firefox patch looks small, is there no way to get some feedback from them ? no firendly insider :) ?

Kloenk · 2020-06-01T08:43:43Z

Is this PR stall? I would like to have it

xaverdh · 2020-12-03T09:19:02Z

closing since #91724 was merged

GrahamcOfBorg added the 8.has: documentation label Mar 24, 2019

GrahamcOfBorg requested review from andir and edolstra March 24, 2019 08:24

GrahamcOfBorg added 10.rebuild-darwin: 11-100 10.rebuild-linux: 11-100 labels Mar 24, 2019

andir reviewed Mar 24, 2019

View reviewed changes

xaverdh force-pushed the firefox-configurable-env branch from 397120f to e3ead5d Compare March 25, 2019 12:20

GrahamcOfBorg requested a review from andir March 25, 2019 12:31

GrahamcOfBorg added 10.rebuild-darwin: 1-10 and removed 10.rebuild-darwin: 11-100 labels Mar 25, 2019

xaverdh force-pushed the firefox-configurable-env branch from e3ead5d to bd23c9d Compare March 26, 2019 18:04

infinisil requested changes Mar 27, 2019

View reviewed changes

xaverdh force-pushed the firefox-configurable-env branch from bd23c9d to 48251e6 Compare March 27, 2019 14:31

xaverdh added 3 commits March 27, 2019 16:27

firefoxPackages: add option to install autoconfig file

8efe930

This adds an option installAutoConfig, which installs an autoconfig.js file in the appropriate subdirectory of the firefox runtime.

firefox: enable generation of autoconfig file (autoconfig.js)

745e659

xaverdh force-pushed the firefox-configurable-env branch from 48251e6 to 38cd961 Compare March 27, 2019 15:31

xaverdh added 2 commits March 27, 2019 16:40

wrapFirefox: add user configuration options to the wrapper

6cd77f9

This uses MOZ_POLICIES_DIR and MOZ_AUTOCONFIG_DIR to point firefox to the users configuration.

nixpkgs doc: add package notes for firefox

4509e3d

This documents configuring firefox by passing options to the wrapper.

xaverdh force-pushed the firefox-configurable-env branch from 38cd961 to 4509e3d Compare March 27, 2019 15:41

xaverdh mentioned this pull request Aug 21, 2019

firefox global config not working #67117

Closed

ryantm added 2.status: merge conflict and removed 2.status: merge conflict labels Oct 3, 2020

xaverdh closed this Dec 3, 2020

xaverdh mentioned this pull request Dec 7, 2020

Firefox extensions discussion #105783

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Firefox configurable #58195

Firefox configurable #58195

xaverdh commented Mar 24, 2019 •

edited

andir left a comment

xaverdh commented Mar 24, 2019

7c6f434c commented Mar 24, 2019

andir commented Mar 24, 2019 •

edited

7c6f434c commented Mar 24, 2019

andir commented Mar 25, 2019

xaverdh commented Mar 25, 2019

infinisil Mar 27, 2019

xaverdh Mar 27, 2019

infinisil Mar 27, 2019

xaverdh Mar 27, 2019

infinisil Mar 27, 2019

xaverdh Mar 27, 2019

infinisil Mar 27, 2019

xaverdh Mar 27, 2019

infinisil Mar 27, 2019

7c6f434c Mar 27, 2019

xaverdh Mar 27, 2019

infinisil Mar 27, 2019

xaverdh Mar 27, 2019

nbp commented Mar 29, 2019

xaverdh commented Mar 29, 2019

xaverdh commented Mar 29, 2019

infinisil commented Apr 1, 2019 •

edited

nbp commented Apr 1, 2019

andir commented Apr 24, 2019 •

edited

teto commented Jul 17, 2019

Kloenk commented Jun 1, 2020

xaverdh commented Dec 3, 2020

Firefox configurable #58195

Firefox configurable #58195

Conversation

xaverdh commented Mar 24, 2019 • edited

Motivation for this change

Things done

andir left a comment

Choose a reason for hiding this comment

xaverdh commented Mar 24, 2019

7c6f434c commented Mar 24, 2019

andir commented Mar 24, 2019 • edited

7c6f434c commented Mar 24, 2019

andir commented Mar 25, 2019

xaverdh commented Mar 25, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nbp commented Mar 29, 2019

xaverdh commented Mar 29, 2019

xaverdh commented Mar 29, 2019

infinisil commented Apr 1, 2019 • edited

nbp commented Apr 1, 2019

andir commented Apr 24, 2019 • edited

teto commented Jul 17, 2019

Kloenk commented Jun 1, 2020

xaverdh commented Dec 3, 2020

xaverdh commented Mar 24, 2019 •

edited

andir commented Mar 24, 2019 •

edited

infinisil commented Apr 1, 2019 •

edited

andir commented Apr 24, 2019 •

edited