Trying to understand my supply chain

Help
1

I recently made a nixos desktop setup that meets my needs well, but I noticed a lot of packages installed or configured in the /etc/nixos/configuration.nix (or hardware.nix) files aren’t usually officially supported by the project’s developers. I also noticed that category.example-package-or-feature.enable = true seems to install a package without it being put in the pkgs thing.

Security of my system is very important to me. I’m not sure exactly what the supply chain for my config looks like.

Here is what I’m confused on:

  1. When you’re doing a category.something.enable or configuring it otherwise like that, are those packages very widely used ones and marked as “safe” by the community? Or is it just another way of installing a miscellaneous package from the catalog?
  2. When I install a package that I personally trust, but the nix package isn’t maintained by the project developers/admins are they able to on the fly switch the package’s source repository to something malicious?
  3. Is there a way to do an audit to see which packages are installed on a given system (this one is less important to me but would still be nice to know.)

I would really appreciate clarification on these points.

Thanks for your time reading this.

2

Try to forget the word ‘install’. It means nothing here.

The question ‘what packages are in my store’ is a coherent one, with a simple answer: ls /nix/store.

The question ‘what packages are referenced by my system profile’ is also a coherent one, with a different answer: nix-store --query --requisites /run/current-system. This will be a subset of the first thing. But don’t think that something in your store but not in your profile (such as, but not limited to, older versions of packages) is equivalent to, for example, a cached package file in Arch. It’s a live copy of the software, and any user can use it via nix-shell or by invoking a binary by its store path. But if not referenced by a retained generation of the configuration, it could also be deleted at any time by garbage collection.

If you use nix-env to maintain a user profile imperatively, or if you use users.users.<name>.packages, or if you use Home Manager, you also may want to know ‘what packages are referenced by my user profile’: nix-store --query --requisites ~/.local/state/nix/profile (if you’re using XDG base directories) or nix-store --query --requisites ~/.nix-profile.

When you set, for example, programs.whatever.enable, what that generally does is add a version of the program to your system profile that has been wrapped to use the specific configuration that you can determine with the other programs.whatever options. This differs from simply adding whatever to environment.systemPackages, which gives you a version of the program that is not specially configured (it will probably use your dotfiles instead). programs.whatever.enable may also set other NixOS configuration options that make whatever function correctly: open firewall ports, add systemd services, set D-Bus policy, etc. In NixOS, all of this is declarative: there are no configuration files left around by old configuration values, outside of the store.

Having a module — a category.something.enable option — is no indicator of additional safety beyond being packaged in Nixpkgs at all. It just indicates that someone cared enough about the experience of using that package to give it some special declarative configuration options.

A Nixpkgs committer could do this (there are 200-odd of us). A mere maintainer could not, without getting approval from a committer (or, theoretically, exploiting some sort of bug in the r-ryantm/nixpkgs-update infrastructure).

11 Likes
Nixos-rebuild triggers enormous rebuilds
3

Thanks for the help and clarification! I think I can be reasonably confident with NixOS’s base security for now.