Permit `builtins.storePath` in pure evaluation mode #402

New issue

Open

opened 2024-06-18 23:09:04 +00:00 by jade · 3 comments

jade commented

2024-06-18 23:09:04 +00:00

Owner

This was discussed here: https://github.com/NixOS/nix/issues/5868

Essentially, it is not a purity break to do this, since you could in principle reconstitute the store path yourself (but there are reasons it may be impossible).

Eelco's argument against this is that it lets you make binary distributions of software that don't have build instructions and depend on the build-host state, but we already do that in nixpkgs! Just look at how the factorio derivation works: it uses a bogus FOD with a hash that happens to match someone's earlier nix-store --add-fixed. It doesn't seem like a very compelling argument since the FOD crimes are actually a lot easier and less surprising for someone to be doing and are permitted in pure mode (also the FOD crimes working is a "security issue" according to some, but shrug imo overblown and should be solved by a FOD verifier run in CI on newly added stuff or just periodically).

The other case it, I guess, permits, is fetching something input-addressed that only exists on a substituter but you don't have the actual derivation for, but, maybe don't do that then?

The one other conceivable argument against this is that the nix evaluator in pure mode is currently a "sandbox" that, if someone is foolishly running it in a multi-tenant setup (don't do this!! surely there are bugs!) doesn't let you invent store paths of some other customer's source code with just a leak of its store path hash and then get its actual contents, if the only access you have is pure-mode nix evaluation but not shell access. We would have to loudly say we are doing it, but it seems like this would be nonetheless strictly an improvement in the status quo for us at least.

I do suspect that such a "leak" already exists if you just use a flake input by absolute path, so it doesn't really feel like a problem unless someone is mysteriously running such a foolish service without flake support, which should be approximately nobody.

There's very little reason not to do this IMO and a lot of upside.

@roberth argues that this should exist to be able to construct arbitrary string contexts from the Nix language, and we absolutely concur.

I am nonetheless posting here in case anyone else has opinions about it.

This was discussed here: https://github.com/NixOS/nix/issues/5868 Essentially, it is not a purity break to do this, since you could in principle reconstitute the store path yourself (but there are reasons it may be impossible). Eelco's argument against this is that it lets you make binary distributions of software that don't have build instructions and depend on the build-host state, but we already do that in nixpkgs! Just look at how the factorio derivation works: it uses a bogus FOD with a hash that happens to match someone's earlier `nix-store --add-fixed`. It doesn't seem like a very compelling argument since the FOD crimes are actually a lot easier and less surprising for someone to be doing and *are* permitted in pure mode (also the FOD crimes working is a "security issue" according to some, but shrug imo overblown and should be solved by a FOD verifier run in CI on newly added stuff or just periodically). The other case it, I guess, permits, is fetching something input-addressed that only exists on a substituter but you don't have the actual derivation for, but, maybe don't do that then? The one other conceivable argument against this is that the nix evaluator in pure mode is currently a "sandbox" that, if someone is foolishly running it in a multi-tenant setup (don't do this!! surely there are bugs!) doesn't let you invent store paths of some other customer's source code with just a leak of its store path hash and then get its actual contents, if the only access you have is pure-mode nix evaluation but not shell access. We would have to loudly say we are doing it, but it seems like this would be nonetheless strictly an improvement in the status quo for us at least. I do suspect that such a "leak" already exists if you just use a flake input by absolute path, so it doesn't really feel like a problem unless someone is mysteriously running such a foolish service without flake support, which should be approximately nobody. There's very little reason not to do this IMO and a lot of upside. @roberth argues that this should exist to be able to construct arbitrary string contexts from the Nix language, and we absolutely concur. I am nonetheless posting here in case anyone else has opinions about it.

👍 2

jade added the

RFD

label 2024-06-18 23:09:04 +00:00

lix-bot commented

2024-06-18 23:38:00 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1482 ("libexpr: fix accessing uninitialized values and fix pure-eval docs")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1482](https://gerrit.lix.systems/c/lix/+/1482) ("libexpr: fix accessing uninitialized values and fix pure-eval docs")

lix-project referenced this issue from a commit

2024-06-19 03:32:07 +00:00

libexpr: fix accessing uninitialized values and fix pure-eval docs

alois31 commented

2024-06-23 14:33:30 +00:00

Member

Like some people have discovered by now, most of what builtins.storePath can do also can be implemented using builtins.appendContext, which is already allowed in pure evaluation mode.

Like some people have discovered by now, most of what `builtins.storePath` can do also can be implemented using `builtins.appendContext`, which is already allowed in pure evaluation mode.

jade added the

Area/evaluator

label 2024-06-24 23:48:33 +00:00

bacchanalia commented

2024-08-30 23:28:44 +00:00

Member

I believe the following definition of builtins.storePath via builtins.appendContext is functionally equivalent to the original, but I haven't verified in the the source code yet.

storePath = path: builtins.appendContext path { ${path} = { path = true; };

I believe the following definition of `builtins.storePath` via `builtins.appendContext` is functionally equivalent to the original, but I haven't verified in the the source code yet. ``` storePath = path: builtins.appendContext path { ${path} = { path = true; }; ```