Firefox nix addon support

[Qubasa]

Motivation for this change

This pull request comes with a bunch of things.
First and foremost you can now add addons to firefox which are pinned to a specific version.
If you remove the addon from your nix config it will also be removed from every firefox profile.
If you change the version of the addon in the configuration it also updates the versions in every profile.
This was terribly difficult to get to work!

The second thing that has been added is a global config for Firefox settings that can't be changed by the user in the respective Firefox profile.

This is the overhauled version of: #74297

Example usage:

{ config, pkgs, ... }:

let
  fetchfirefoxaddon=callPackage ./modules/fetchfirefoxaddon {};
  callPackage = pkgs.lib.callPackageWith (pkgs);
  wrapper = pkgs.callPackage ./overlays/wrapper.nix { fx_cast_bridge=pkgs.unstable.pkgs.fx_cast_bridge; };

  hardenedFirefox= wrapper pkgs.firefox-unwrapped {
    extraExtensions = [
      (fetchfirefoxaddon {
        name = "ublock";
        url = "https://addons.mozilla.org/firefox/downloads/file/3679754/ublock_origin-1.31.0-an+fx.xpi";
        sha256 = "1h768ljlh3pi23l27qp961v1hd0nbj2vasgy11bmcrlqp40zgvnr";
      })
      (fetchfirefoxaddon {
         name = "https-everywhere";
         url = "https://addons.mozilla.org/firefox/downloads/file/3574076/https_everywhere-2020.5.20-an+fx.xpi?src=search";
         sha256 = "10wjimk9wrdfja6f73pppm7pmb1jl838p7siwh4vzlw1sjszr57c";
       })
       (fetchfirefoxaddon {
         name = "certificate-pinner";
         url = "https://addons.mozilla.org/firefox/downloads/file/3599612/certificate_pinner-0.17.10-an+fx.xpi";
         sha256 = "15qyjqca252pf28vv636fwya28pj3nnbywpkpm6cwmj1m64pmdsl";
       })
    ];

    extraPolicies = {
      CaptivePortal = false;
      DisableFirefoxStudies = true;
      DisablePocket = true;
      DisableTelemetry = true;
      DisableFirefoxAccounts = true;
      FirefoxHome = {
        Pocket = false;
        Snippets = false;
      };
       UserMessaging = {
         ExtensionRecommendations = false;
         SkipOnboarding = true;
       };
    };

    extraPrefs = ''
      // Show more ssl cert infos
      lockPref("security.identityblock.show_extended_validation", true);

      // Enable userchrome css
      lockPref("toolkit.legacyUserProfileCustomizations.stylesheets", true);

      // Enable dark dev tools
      lockPref("devtools.theme","dark");
    '';

    gdkWayland = true;
  };

in {

environment.variables = {
  BROWSER = ["firefox"];
};

environment.systemPackages = with pkgs; [
  # firefox
  hardenedFirefox
];

}

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

@Lassulus

[eyJhb]

I am all in, for being able to customize Firefox even more, but I have a feeling that this is more of a home-manager thing, as it would be lovely to be able to configure pr. profle, instead of globally.

Ideally, we should support these things:

1. Globally pr. machine like above
2. Pr. user (already a switch - https://bugzilla.mozilla.org/show_bug.cgi?id=1583466 )
3. Pr. profile, which would allow users to have multiple profiles, with different settings (requires patching Firefox)

I think we should try to achieve all these, with the least amount of hacks, and working WITH Firefox/Mozilla in this case.
This means by utilizing policies.json 100% for extensions install, etc.

[Mic92]

To summarize our mumble discussion. I suggest to move the firefox extension code to its builder that allows to override a build phases rather than passing in data. However @luis-hebendanz does not want to implement that, so if someone else wants to pick it up, go for it.

[Qubasa]

I am all in, for being able to customize Firefox even more, but I have a feeling that this is more of a home-manager thing, as it would be lovely to be able to configure pr. profle, instead of globally.

Ideally, we should support these things:

1. Globally pr. machine like above

2. Pr. user (already a switch - https://bugzilla.mozilla.org/show_bug.cgi?id=1583466 )

3. Pr. profile, which would allow users to have multiple profiles, with different settings (requires patching Firefox)

I think we should try to achieve all these, with the least amount of hacks, and working WITH Firefox/Mozilla in this case.
This means by utilizing policies.json 100% for extensions install, etc.

I strongly disagree to make this a home manager thing. Organizations want to deploy specific configs of Firefox to employees, the current method ensures complete immutability in this regard, home-manager can not guarantee that. Installation of addons can only be done through the policies.json since the newer Firefox versions which means home-manager can't do that. The policies.json are already used 100% for installing the addons in this pull request.
Patching Firefox for multi user profiles is neat but completely out of scope, at least for this pull request.
Also the chrome addon manager in NixOS also works globally.

[eyJhb]

Well, actually because of a patch here - https://bugzilla.mozilla.org/show_bug.cgi?id=1583466, it is actually possible to do pr. user policies.json.

But, a thing that might change this whole thin, if we are only going for policies.json here, is to use /etc/firefox/policies/policies.jsonas documented here - https://github.com/mozilla/policy-templates , which does not require a rebuild or anything. And could be a module on its own.
But I am unsure, if that is the goal :)

Also, supporting both would be nice, but I see the pro in both!

[Mic92]

Well, actually because of a patch here - bugzilla.mozilla.org/show_bug.cgi?id=1583466, it is actually possible to do pr. user policies.json.

But, a thing that might change this whole thin, if we are only going for policies.json here, is to use /etc/firefox/policies/policies.jsonas documented here - mozilla/policy-templates , which does not require a rebuild or anything. And could be a module on its own.
But I am unsure, if that is the goal :)

Also, supporting both would be nice, but I see the pro in both!

It could be a simple symlink to the package in that case.

[Qubasa]

@Mic92 I added a builder called fetchfirefoxaddon, I also updated my first comment above with an example how to use it now.
Quick overview:

 extraExtensions = [
      (fetchfirefoxaddon {
        name = "ublock";
        url = "https://addons.mozilla.org/firefox/downloads/file/3679754/ublock_origin-1.31.0-an+fx.xpi";
        sha256 = "1h768ljlh3pi23l27qp961v1hd0nbj2vasgy11bmcrlqp40zgvnr";
      })
]

[eyJhb]

Is extensions for Firefox something we want to cover in Nixpkgs?

EDIT: as in having nixpkgs.firefoxExtensions.ublock

[Atemu]

They're some of the most security critical and most used programs, I think packaging them would be a good idea.

[Mic92]

They're some of the most security critical and most used programs, I think packaging them would be a good idea.

I am only a bit concerned that they get out of date on stable channels. Also on unstable they would be a automatic update mechanism required.

[eyJhb]

That is also my main concern, as channels can hang for a while.

I know that @rycee has a job on Gitlab that automatically updates the Firefox addons that you can use with home-manager ( https://gitlab.com/rycee/nur-expressions/-/tree/master/pkgs/firefox-addons )

Maybe they could be placed in the community repo? Even though that seems like a hacked solution.

PS: Also this might be a separate issue for discussion?

[Mic92]

Yeah. Having a firefox-addon repo sounds like a great idea.

[Atemu]

automatic update mechanism required.

If we updated them automatically anyways, backporting to stable would be trivial.

[eyJhb]

Created a discussion here - #105783

[Mic92]

automatic update mechanism required.

If we updated them automatically anyways, backporting to stable would be trivial.

Backporting is still some amount of work that could be avoided if both stable/unstable users could use a repo independent from nixpkgs.

[edolstra]

This looks indented incorrectly.

[Qubasa]

Its not because toFile does not strip tabs away and this file format needs a comment without spaces at the beginning

[aszlig]

@luis-hebendanz: toFile only takes strings, the stripping is caused by ''...''. I don't however see any tab characters involved here. Checking this quickly via nix repl results in:

nix-repl> builtins.readFile (builtins.toFile "mozilla.cfg" ''
                  // First line must be a comment
          
                  // Disables addon signature checking
                  // to be able to install addons that do not have an extid
                  // Security is maintained because only user whitelisted addons
                  // with a checksum can be installed
                  lockPref("xpinstall.signatures.required", false);
                  ...
          '')
"// First line must be a comment\n\n// Disables addon signature checking\n// to be able to install addons that do not have an extid\n// Security is maintained because only user whitelisted addons\n// with a checksum can be installed\nlockPref(\"xpinstall.signatures.required\", false);\n...\n"

nix-repl>

[taku0]

Should we have an option to disable the policy, and disable the policy by default? If this patch is merged to the stable, existing users will lose their installed add-ons. It is not an ideal experience.

[Qubasa]

I opened up a fix here #105796

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/some-applications-firefox-mousepad-do-not-open-anymore-with-my-settings-but-as-first-time-opened-after-nightly-nixos-update-using-unstable-channel/16489/3