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:
https://github.com/NixOS/nixpkgs/issues/67166
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 extra-sandbox-paths
contains /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.