Nix-rebuild prompts for `nixConfig` values already enabled on the system

Help
1

Hi all, I’m new (~5 weeks) to NixOS and have recently starting porting my configuration to flakes.

In my flake.nix, I define nixConfig.extra-substituters and nixConfig.extra-trusted-public-keys to enable the use of a community cache. As expected, I’m prompted as to whether I would like to trust these values when I sudo nixos-rebuild switch --flake.

I would like to disable the warnings for the particular values I have set. I would like to do so declaratively, so saying ‘y, please trust this value permanently’ isn’t want I want. My expectation was that setting the same values for those same nixConfig keys on a system basis (using nix.settings) would disable the prompts — why prompt a user to enable an option that is already enabled? — but I found that I was still prompted. Is this expected behavior? Is there something I am missing? What can I do to achieve the desired effect?

I tried a few different things, notably using nix.settings.substituters directly instead of nix.settings.extra-substituters, using both at once, and using both settings in both NixOS and home-manager at once. I was able to confirm the settings values were register using nix config show.

Here’s an image showing my attempt to set every relevant-seeming Nix setting, confirming they’re active, and still getting the prompt I’m trying to avoid (let me know if you’d like a text-based copy of this instead of an image):

Screenshot 2026-04-29 114839
Screenshot 2026-04-29 1148391919×1056 171 KB

Using equivalent command-line flags instead of nixConfig isn’t great because that would back me into using a shell script instead of just using nix, and I’m not comfortable with using--accept-flake-config. Short of entirely removing `nixConfig` from the flake or just sucking it up and letting Nix permanently trust the values imperatively, I’m not aware of any other solutions. I couldn’t find any relevant discussion online when I searched.

My config is here (locked to time of post: link; I can alternatively provide snippets if that’s better!); the system in question is the wsl host in flake, which is mostly configured in hosts/loaner-laptop/. This is a NixOS-WSL install, I have not yet tested a NixOS install on bare metal or in a VM. Here’s the output of nix-info -m and wsl --info:

  • system: "x86_64-linux"
  • host os: Linux 6.6.114.1-microsoft-standard-WSL2, NixOS, 26.05 (Yarara), 26.05.20260427.1c3fe55
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.34.6
  • nixpkgs: /nix/store/l61vfkyy0qrnz9bmgx84fa7z3bjzhyp4-source
  • WSL version: 2.7.1.0
  • Kernel version: 6.6.114.1-1
  • WSLg version: 1.0.73
  • MSRDC version: 1.2.6676
  • Direct3D version: 1.611.1-81528511
  • DXCore version: 10.0.26100.1-240331-1435.ge-release
  • Windows version: 10.0.26200.8037
    • I am, to be clear, running Win11 25H2 (NixOS soon :tm:), not sure why it registers as something that looks like Win10.

Happy to answer any clarifying questions. If I’m hitting the X/Y problem here, I’m happy to field opinionated suggestions about different approaches to dismissing the prompts. Thanks!

2

Adding substituters to nixConfig is generally not recommended. It will never work in practice because users using your flake should never use it with a user who is actually permitted to set those settings.

Given you’re also configuring NixOS with a flake, rather than trying to set these values for drive-by contributors, you really shouldn’t be using nixConfig.

Use the NixOS configuration instead.

2 Likes
3

I feel like there should be some way that these prompts check if you are a trusted user first before showing them.

Why? I always set myself as a trusted user in nix, and many others do too. Actually my config is such that everyone in wheel can do it as they can get root access to the system anyhow and mess stuff up anyhow (including changing systemwide nix.conf).

4

Because that makes your user effectively root, rather than going through the controlled channel of sudo or whatever other permission management you may use. Even if you’re in wheel it still makes sure the user is not an automated script. This completely breaks the security model.

5

I do see an argument for making sure the user is not a script with a password prompt, and think something like that (password prompt for trusted user settings) should probably be implemented into nix (is there prior discussion/issues for this?), but for now setting myself as a trusted user is more convenient.

6

You’re an excellent example of some very basic security concepts here, people will always find ways to break security for convenience.

It’d probably be best if nixConfig simply didn’t permit setting those keys; they just invite people adding substituters without even thinking about the impact, and clearly promote insecure daemon settings to boot. Ah well.

Odds are slim you’ll be pwned in practice, because obscurity does help, but RCE exploits are more risky on your systems. YOLO and all, but please don’t aim for committer status on anything important.

1 Like
7

That makes sense, I think I’ll adopt that solution. I had read that being marked as a trusted user makes you root and that setting this value requires being a trusted user, but I hadn’t put the two together to come to the conclusion that I shouldn’t be doing this. Thank you!

1 Like
8

I don’t like the current state of nixConfig substituters (as I said, there should at least be a password prompt in line with sudo before trusting) but it’s much nicer than alternatives. Also see xkcd: Authorization

1 Like
9

You could use a different group for trusted nix access and only be able to run nix (or any other program) as that group through sudo -g.

1 Like
10

Unfortunately that would not work well with direnv, unless you did sudo -gnix-trusted -i before going in. Sounds like a good solution if you care more about “programs can’t randomly trust caches without going through passwords” however. Also you would need to set perms on ~/.local/share/nix/trusted-settings.json to make only nix-trusted be able to write to it i think.