Including the sandbox-paths in the derivation would make Nix completely unusable. Suppose you did fold sandbox-paths into the output hash by having it in the derivation. My busybox is busybox-1.37.0 at one store path; yours is a different version at a different path. The same derivation would then hash to different outputs on our two machines, and binary-cache sharing across would collapse.
I don’t understand why this would be an issue. The whole point of Nix is to make implicit dependencies explicit, and to only substitute things which are “the same” according to that standard. Why would it be an issue with the sandbox?
The issue is any build sandbox will remain "leaky" in a sense,
Take for example broken hardware, i.e. a CPU with a buggy FPU for which floating point instructions are used during the build. Running the same build on different machines can result in drastically different output builds (pathologically so, if you want to construct an example like the one in OP). It would not be reasonable to take some kind of machine hash into the derivation, even though the build machine is in a real sense an input/dependency of the computation you're running.
True, but pinning the sandbox packages would still be an improvement over not pinning them, or wouldn't it? I think that was the key point of the parent comment, making only packages explicit (i.e. what can be made explicit cheaply) and not everything in some absolutist way.
(author) I agree -- that is at least better to highlight there is a path forward.
I'm surprised about the default here. Clearly it's not needed since Guix doesn't have it.
At first I had thought /bin/sh must be present for POSIX compliance (if we even care about that) but a little searching now claims that's not the case.
Given that bash is a necessary bootstrap binary for Nix itself and we do shebang rewrites.... why even support /bin/sh in the first place...
My impression is we did /bin/sh basically as a convenience, to make it easier for package authors to not have to make sure they rewrite all shell references prior to building. Shebangs are the obvious source of references to /bin/sh but they're not the only one.
Even if you were to offer specifically that as a convenience, there have to be better ways to do it than impurely just wiring it into the sandbox. For example, could this have been provided in the build environment by default in mkDerivation maybe? Using the busybox sh from whatever pkgs instance your mkDerivation is from?
Sure, that's also a bad place for such conveniences, but by far less naughty. At least everything will be content-addressed correctly.
Provided how? I think stdenv will already provide bash/sh in PATH, but that's different than providing the path /bin/sh which a lot of things have hardcoded.
I was assuming that, every build being its own sandbox, they get to mess with their filesystem view arbitrarily and can just symlink stuff to /bin/sh. But I realize now that's probably not a thing, among other reasons since unsandboxed builds also exist and are (somewhat) expected to work for the same derivations.
there are heinous reasons we might need bin sh in ways we may not be able to patch. like i just submitted a horrible bash Python polyglot to buck2 to do relative resolution of python shebangs and these things are totally runtime generated. alas!
asymmetric | 4 days ago
I don’t understand why this would be an issue. The whole point of Nix is to make implicit dependencies explicit, and to only substitute things which are “the same” according to that standard. Why would it be an issue with the sandbox?
vpr | 4 days ago
The issue is any build sandbox will remain "leaky" in a sense,
Take for example broken hardware, i.e. a CPU with a buggy FPU for which floating point instructions are used during the build. Running the same build on different machines can result in drastically different output builds (pathologically so, if you want to construct an example like the one in OP). It would not be reasonable to take some kind of machine hash into the derivation, even though the build machine is in a real sense an input/dependency of the computation you're running.
ph14nix | 4 days ago
True, but pinning the sandbox packages would still be an improvement over not pinning them, or wouldn't it? I think that was the key point of the parent comment, making only packages explicit (i.e. what can be made explicit cheaply) and not everything in some absolutist way.
fzakaria | 4 days ago
(author) I answered it a little nicer here https://discourse.nixos.org/t/the-nix-sandbox-is-a-hidden-input/79269/3?u=fzakaria
vpr | 4 days ago
What is the status on
ca-derivations? I feel they have been in development/unstable for over 5 years now.jackdk | 4 days ago
There were a bunch of changes to it documented in the Nix 2.35 release notes but I haven't heard any major announcements.
riking | 4 days ago
The list of
sandbox-pathskeys without their values seems like a plausible fix.fzakaria | 4 days ago
(author) I agree -- that is at least better to highlight there is a path forward. I'm surprised about the default here. Clearly it's not needed since Guix doesn't have it.
At first I had thought
/bin/shmust be present for POSIX compliance (if we even care about that) but a little searching now claims that's not the case.Given that bash is a necessary bootstrap binary for Nix itself and we do shebang rewrites.... why even support
/bin/shin the first place...lilyball | 4 days ago
My impression is we did
/bin/shbasically as a convenience, to make it easier for package authors to not have to make sure they rewrite all shell references prior to building. Shebangs are the obvious source of references to/bin/shbut they're not the only one.muvlon | 4 days ago
Even if you were to offer specifically that as a convenience, there have to be better ways to do it than impurely just wiring it into the sandbox. For example, could this have been provided in the build environment by default in
mkDerivationmaybe? Using the busybox sh from whatever pkgs instance your mkDerivation is from?Sure, that's also a bad place for such conveniences, but by far less naughty. At least everything will be content-addressed correctly.
lilyball | 4 days ago
Provided how? I think
stdenvwill already provide bash/sh inPATH, but that's different than providing the path/bin/shwhich a lot of things have hardcoded.muvlon | 4 days ago
I was assuming that, every build being its own sandbox, they get to mess with their filesystem view arbitrarily and can just symlink stuff to /bin/sh. But I realize now that's probably not a thing, among other reasons since unsandboxed builds also exist and are (somewhat) expected to work for the same derivations.
fzakaria | 4 days ago
why /bin/sh only though seems weird; If it's shebang we rewrite them and /bin/bash seems just as prolific as /bin/sh
/shrug
jade_ | 3 days ago
there are heinous reasons we might need bin sh in ways we may not be able to patch. like i just submitted a horrible bash Python polyglot to buck2 to do relative resolution of python shebangs and these things are totally runtime generated. alas!
fzakaria | 3 days ago
You might like https://fzakaria.com/2026/08/01/a-c++-toolchain-from-357-bytes-in-bazel Maybe you are interested in porting it to buck2