Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox nix addon support #91724

Merged
merged 8 commits into from Dec 3, 2020
Merged

Conversation

Qubasa
Copy link
Contributor

@Qubasa Qubasa commented Jun 28, 2020

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
Copy link
Member

eyJhb commented Jul 17, 2020

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
Copy link
Member

Mic92 commented Jul 17, 2020

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
Copy link
Contributor Author

Qubasa commented Jul 18, 2020

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
Copy link
Member

eyJhb commented Jul 18, 2020

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
Copy link
Member

Mic92 commented Jul 19, 2020

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 Qubasa requested a review from Mic92 November 30, 2020 15:40
@Qubasa
Copy link
Contributor Author

Qubasa commented Nov 30, 2020

@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
Copy link
Member

eyJhb commented Dec 3, 2020

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

EDIT: as in having nixpkgs.firefoxExtensions.ublock

@Atemu
Copy link
Member

Atemu commented Dec 3, 2020

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

@Mic92
Copy link
Member

Mic92 commented Dec 3, 2020

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
Copy link
Member

eyJhb commented Dec 3, 2020

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
Copy link
Member

Mic92 commented Dec 3, 2020

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

@Qubasa Qubasa deleted the firefox-nix-addon-support branch December 3, 2020 10:55
@Atemu
Copy link
Member

Atemu commented Dec 3, 2020

automatic update mechanism required.

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

@eyJhb
Copy link
Member

eyJhb commented Dec 3, 2020

Created a discussion here - #105783

@Mic92
Copy link
Member

Mic92 commented Dec 3, 2020

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.

};

mozillaCfg = builtins.toFile "mozilla.cfg" ''
// First line must be a comment
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks indented incorrectly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link
Contributor

taku0 commented Dec 3, 2020

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 Qubasa mentioned this pull request Dec 3, 2020
10 tasks
@Qubasa
Copy link
Contributor Author

Qubasa commented Dec 3, 2020

I opened up a fix here #105796

@nixos-discourse
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants