Is there a tool to abort building the nix-store if through the config secrets would be included, or in other words anything with a high entropy? Where would one declare / hook into to run such a test when building the nix-store?
At work we have pre-commit hooks and CI jobs for git repositories as a last line of defense to warn about such incidents. I’m wondering if and how that is done in nix/nixos and if there are already tools for this.
If you are already checking with pre-commit then the simplest solution to this is, that no one commits any secrets to the git repository holding the nix files.
I missed to add some context: I happend to include an age secret key into the nix store because I referenced the age keys file as Path, not as string. The former copies the file into the store, the latter resolves it at runtime.
Then there are remote builders and what you’d like to have here is that if you reference a file by Path such that nix includes the file in the build and would be sent to the remote builder I’d like to detect this and error out before it gets send to the remote builder. How I understand it a post hook would only after everything was sent to the remote builder notice the error. It would help though for local builds before pushing them to a remote machine.
Of course you could in this particular example go to the software module (sops-nix in this case) and handle this specific case there, but as this might happen in any nix module I think a general solution would be less error prone (not from a detection point of view) than lets say having documentation for module maintainers to avoid this (accepting a Path/copy type/reference for key files) as bad practice
So the problem is not to detect secrets in the git repository but the ones that get copied from the disk to the nix store
Yea, I’m not sure this is solvable. Nix is not smart enough to know which information should or shouldn’t be allowed in the store. Simply being high entropy isn’t a very good test, because all sorts of high entropy things are valid, like hashes and public keys. And where exactly would this be hooked into anyway? To just block any additions to the store that meet whatever this criteria is would mean a very low level change to Nix itself; and tracking that info all the way from any builtins.readFile or path reference down to this low level means a very far-reaching change.
I have to say, not checking secrets into git seems like the solution to me, for more reasons than this. I generally consider checking secrets into git a bad idea that is simply asking for trouble, even if they’re encrypted.
The secret key was never part of the git repo. It was referenced in the git repo, but was stored in /root
as proposed in the security channel on matrix I think with
I propose an effort to encourage restriction of variables holding sensitive file references to not accept Path types but only string types and as part of this effort (tracked with an issue in nixpkgs) compose a list of affected packages, notify the maintainers and establish this is packaging guidelines.
This is one of the rationales for the Nix pure evaluation to only consider git-added files. This mode of operation is the default with flakes.
It would prevent referring+copying a “/root/whatever” while evaluating/building a NixOS system out of “/home/user/my-config-in-git”.
On the other hand, this default can then confuse people when they forget to add a file and Nix says it doesn’t exist. Perhaps the error message can be better.
Interesting! I did not know nix pure evaluation.
Can you point me to where or how one does this without flakes? I’ve yet to touch those and these are also not what you first encounter “by default” when starting with nix / nixos so I’d argue that this, if it is a suitable work-around, be done with flake-less nixos too.
To test I tried nix-instantiate --strict "<nixpkgs/nixos>" -A system --arg pure-eval true which I think does not what you are getting at 
It at least does not work. How do I instruct nixos-rebuild (switch) and nix-instantiate to use pure-eval mode if at all possible?
More radical perhaps: from my current point of view I think pure-eval mode should also be the default with nixos-rebuild + channels / without flakes, documentation on this needs to exist in the manual and wiki and it should be discouraged to use impure eval mode at least for the system configuration. With good documentation I believe that this can work out! At least this should be the approach as long as flakes are not a “native citizen” when using nixos.