| 28 Jul 2025 |
 raitobezarius | (s/Darwin// tbh, it's not about Darwin specifically) | 02:03:38 |
 EsperLily [she/her] | i mean what i'm suggesting would be unsandboxed Linux too, though i don't know who actually runs without the sandbox on Linux | 02:03:39 |
 jade_ | i want a better "unsandboxed" darwin sandbox. but that means that the default needs to be sandbox = relaxed, but then derivations have to be able to say "sandbox ok but not a strong one" and aaaaghgg | 02:03:39 |
| jade_ | docker | 02:03:45 |
| raitobezarius | In reply to @esperlily:matrix.org
i mean what i'm suggesting would be unsandboxed Linux too, though i don't know who actually runs without the sandbox on Linux Debian 10 | 02:03:48 |
| jade_ | okay but we don't care about debian making horrible packaging choices :P | 02:04:00 |
| jade_ | that's a them problem | 02:04:04 |
| raitobezarius | yes, but this is a truth | 02:04:04 |
 emily | it's mostly Nixpkgs work that's required to tighten the Darwin sandbox | 02:04:05 |
| raitobezarius | and this has consequences | 02:04:10 |
| 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 |
