AFAICT the primary reason
sandbox = true doesn’t work out of the box on darwin (i.e. without defining a bunch of
extra-sandbox-paths) is because the frameworks aren’t propagating their impure host deps properly. They’re certainly trying, but the impure host deps propagation in general is broken.
I did some investigation in the following issue:
but I don’t have a good-enough grasp of all of the different build input types to know quite what the solution should be. In general what we want is for all
__propgatedImpureHostDeps to propagate upwards to anything that transitively links to it (e.g. when it’s used as
buildInputs) but only propagate to things that directly reference it as a build tool (e.g.
nativeBuildInputs). Otherwise if we always propagate upwards to all references, then e.g. all of
cargo's dependencies will show up in
__impureHostDeps for all rust packages.
In that same issue I list a diff that fixes the existing propagation (it was flat-out broken) which at least causes
__propgatedImpureHostDeps to propagate upwards by a single step (which is suitable for build tools, or for libraries directly referenced by the binary, but not for libraries transitively-depended-upon), and I’m tempted to submit a PR for that, but that alone massively bloats the
__impureHostDeps of basically any darwin package I’ve looked at. I don’t know if there’s any concern about that (how large are the .drv files relative to the full store in general anyway?) but it certainly is a rebuild-the-world scenario, and I’d rather not do that until we have the full solution that works for transitive libraries too.
Note that I don’t know if this fully fixes the sandbox on darwin, because my
/usr/lib /private/tmp /private/var/tmp /usr/bin/env as well (as suggested by someone else, I’ve forgotten who now) and I don’t know if those paths are actually necessary for anything or are just overkill.
Given all of this, I would love to have more input on the issue by people more knowledgable about the various dependency types.