Also, we fixed a couple of security issues! Took a while to get the writeups finalized and published, which is why we hadn’t posted publicly about them anywhere yet.
Pure-eval is not a solution though, the evaluator is not a sandbox and not a security boundary. Ideally, all evaluations of untrusted code would run in a bwrap or any other type of sandbox with a nix daemon process having access to the secrets (also sandboxed).
I understand this is technically correct. But if we can’t trust nix to evaluate untrusted nix expressions safely, we have bigger problems as an ecosystem.
The flakes commands are designed with executing remote flakes as a first-class feature (and “remote” often implies “untrusted,” to some degree).
For example, it’s common to do:
nix build github:some/repo
…which will fetch a remote repo and evaluate its nix expressions.
If pure eval is not secure, you’ve effectively given that (remote) nix expression access to your entire filesystem via builtins.readFile, environment variables via builtins.getEnv, and it could leak secrets via builtins.fetchurl or fetchTarball.
In practice, pure eval should not allow this. But you’re correct that it’s not strictly a security boundary, which I suppose means that nix itself could be subject to exploits that allow bypassing pure eval and gaining arbitrary filesystem or environment access.
This should probably be split off into a separate discussion. There’s definitely a lot to unpack here, but I don’t think I have the trust level for that.