| 28 Jul 2025 |
 EsperLily [she/her] | incidentally it bothers me that "relaxed" means "don't sandbox FOD derivations" because I use "relaxed" in order to use __sandboxProfile and I'd actually rather keep the FOD derivations sandboxed | 02:04:42 |
 jade_ | right sure, but i think that people need to be able to run with the experimental new sandbox policy to be able to report the bugs
okay concept: experimental feature. but still it might want a per drv opt out. :V :V :V :V :V | 02:04:51 |
 emily | no I mean | 02:05:07 |
| emily | sandbox = true fails to build a bunch of stuff in Nixpkgs | 02:05:13 |
 raitobezarius | As you already know, I'm Darwin ignorant, so really, you tell me what direction we need to go | 02:05:14 |
| jade_ | wait it DOES??? christ. this whole setting is such a mess | 02:05:15 |
| raitobezarius | I think the only important thing is that code complexity goes down | 02:05:25 |
| jade_ | i thought it was the latter | 02:05:28 |
| raitobezarius | So that someday registerOutputs is possible to touch without introducing store corruption bugs | 02:05:36 |
| emily | and also I'm pretty sure we can just tighten sandbox = true without another flag because it's already a pain | 02:05:41 |
| emily | but someone has to throw stdenv to channel blockers at it or something | 02:06:03 |
| emily | and actually triage the issues | 02:06:09 |
| emily | it's always easy per package but it adds up | 02:06:13 |
| emily | stuff like getting /tmp out would be tedious but doable | 02:06:33 |
| EsperLily [she/her] | yeah i have no idea who thought it was a good idea to say "relaxed means don't sandbox the FODs" since what it should mean is "enable the escape hatches like __sandboxProfile and __noChroot so derivations can opt in to weakening protections" | 02:06:36 |
| jade_ | https://git.lix.systems/lix-project/lix/issues/936 | 02:20:18 |
| EsperLily [she/her] | hey here's a thought, if the cacert file is actually a store file (if you resolve the path), we could just hard-link it instead of copying it (though this probably only works for chroot, since you're using tmpDir otherwise and there's no guarantee that's on the same volume; you could also perhaps just use chrootRootDir even without chroot though?) | 02:22:26 |
| jade_ | i don't like this because i think it could equivalently be solved without more implementation complexity by a better file copy function | 02:24:26 |
| raitobezarius | In reply to @esperlily:matrix.org
hey here's a thought, if the cacert file is actually a store file (if you resolve the path), we could just hard-link it instead of copying it (though this probably only works for chroot, since you're using tmpDir otherwise and there's no guarantee that's on the same volume; you could also perhaps just use chrootRootDir even without chroot though?) cacert is not a store file in general | 02:24:46 |
| EsperLily [she/her] | it should be on NixOS and nix-darwin? | 02:24:56 |
| raitobezarius | i'm mostly thinking about all the corporate usecases with their zscaler ca that comes from elsewhere | 02:25:20 |
| emily | I still think "add it to the store (potentially with optimization to not needlessly re-add an existing store path)" is the ~optimal solution modulo complexity | 02:25:21 |
| jade_ | and also lix on normal macos i think, since cacert goes into the system profile | 02:25:44 |
| raitobezarius | NixOS already does something quite different | 02:25:47 |
| raitobezarius | which does not make any use of ssl-cert-file today? | 02:25:55 |
| raitobezarius | nix-darwin does use ssl-cert-file and possibly this is a store path yeah | 02:26:07 |
| jade_ | for CoW filesystems (most modern fs), if our file copy is implemented correctly we can just have the copy be equivalent to hardlink | 02:26:11 |
| raitobezarius | in practice | 02:26:20 |
| raitobezarius | copying from /etc to /nix/var/nix/builds/ may or may not end up being optimized away | 02:26:39 |
| jade_ | i also agree that importing to the store should be able to be fast | 02:26:42 |
