Interactive flake settings: nixConfig

Sometimes, when using flakes, you can be prompted interactively for settings. For example:

petrockette@felicette:~/src/petrockette/nix/full$ nix run github:helix-editor/helix/master
do you want to allow configuration setting ‘extra-substituters’ to be set to ‘https://helix.cachix.org’ (y/N)? y
do you want to permanently mark this value as trusted (y/N)? n
do you want to allow configuration setting ‘extra-trusted-public-keys’ to be set to ‘helix.cachix.org-1:ejp9KQpR1FBI2onstMQ34yogDm4OgU2ru6lIwPvuCVs=’ (y/N)? y
do you want to permanently mark this value as trusted (y/N)? n

I am curious, had I selected yfor do you want to permanently mark this value as trusted where that setting would be stored, in the case I changed my mind later or wanted to revisit the saved settings

Ok, sort of nevermind. These are stored in ~/.local/share/nix/trusted-settings.json but it might be nice if such things were a bit more transparent. It is fine to set them there, or anywhere, but it would be nice to not have to hunt things down.

It sort of breaks the values of determinism and reproducibility, at least as far as these are hidden and not under any source control.

There is commentary here but regardless of whether or not this is a good approach, it should not be mysterious, and it should be per-flake, rather than per-user

2 Likes

It does not affect determinism and reproducibility any more than disabling substitution from cache.nixos.org does. It simply provides a short-cut for your local system to substitute and trust outputs from a third-party cache.

The values you’re setting are under source control in the flake you’re running, but we do not want the setting change on your local machine to be under source control, as that can lead to anyone with access to your SCM to trick you into downloading their (possibly compromised) builds.

This sounds like a great beginner PR to nix. Best of luck!

I don’t feel it is mysterious. It is documented, and has been discussed at length online.

It certainly should not be shared between users though. As above, users on the same system would be able to trick you into substituting from caches you don’t trust. There is already settings for the nix daemon and client that allow setting up globally trusted substituters, but this is limited to system operators.

1 Like

Per user is a very intentional design as the substituter doesn’t know about flakes. It only knows about derivations. Derivations don’t have provenance of where they come from (though there is work to fix that) and our substitution algorithm also isn’t provenance aware.

Is that ideal? No. I agree it should be fixex

2 Likes

I am new to fully using nix, though I am a bit more familiar with the nix-lang and the build system, so please take anything I say as coming from an earnest, if somewhat unfamiliar viewpoint. I certainly appreciate all the work everyone has done into making a substantial improvement of the usual approach to package and development managment

Is is often valuable to share these initial roadblocks, as they can help other new users, and help uncover the bindspots that more experience users and developers who have just become used to the way things are done

I did discover some documentation about this on the nix haskell wiki, at the very bottom under IFD and Haskell:

callCabal2nix, which is implicitly used for building Haskell projects, uses IFD.[2][3]. This means that since IFD is disabled by default in certain nix commands,[4] the following commands will be broken for Haskell projects whose flake output specifies multiple system attributes:

nix flake show
nix flake check