| 2 Jul 2025 |
 emily | or it might actually be better to set build-dir to something inaccessible so that the fallback protections in https://gerrit.lix.systems/c/lix/+/3502 trigger. (cc raitobezarius seems suboptimal that those are conditioned on build-dir failing rather than e.g. the permissions of the selected directory being too permissive, which would catch temp-dir but also manually setting build-dir to something risky?) | 14:21:08 |
| emily | fwiw, the comparable logic Nix had makes --keep-failed very annoying on shared machines because you need to be root to look at the resulting failed build directory 😆 | 14:22:05 |
| emily | I think Nix started to chmod stuff back to world-readable after a failed build for that reason, not sure if that carries its own security pitfalls | 14:22:27 |
 raitobezarius | In reply to @emilazy:matrix.org
or it might actually be better to set build-dir to something inaccessible so that the fallback protections in https://gerrit.lix.systems/c/lix/+/3502 trigger. (cc raitobezarius seems suboptimal that those are conditioned on build-dir failing rather than e.g. the permissions of the selected directory being too permissive, which would catch temp-dir but also manually setting build-dir to something risky?) Not a big fan of checking perms because this is actually wrong in presence of Linux ACLs | 14:23:35 |
| raitobezarius | And systemd does make use of ACLs in practice | 14:23:46 |
| raitobezarius | Which hinder load credentials adoption | 14:24:05 |
| emily | well, just check access then? | 14:24:19 |
| raitobezarius | Yeah, that could be the compromise | 14:24:41 |
 WeetHet | I must be missing something, but how does lix clean up the new build dir on macOS? | 14:24:46 |
| emily | but race condition (but maybe you can use an fd instead) (also not sure if the race condition has any security implications, might be wrong-side-of-airtight-hatchway) | 14:24:44 |
| WeetHet | Because it isn't cleaned up on reboot anymore | 14:25:04 |
| emily | successful builds are deleted, failed builds are deleted, so --keep-failed is the only source of leaks | 14:25:20 |
| emily | (or crashes admittedly) | 14:25:48 |
| raitobezarius | Are you observing uncleaned builds for interrupted builds? | 14:25:54 |
| WeetHet | Yes | 14:26:00 |
| emily | the daemon learning its own automatic cleanup logic is somewhat inevitable because it will be required for temp-dir on /nix for case-sensitive-by-default on macOS to kill off the case hack | 14:26:28 |
| raitobezarius | Yeahhhhh | 14:34:07 |
| raitobezarius | In reply to @weethet:catgirl.cloud
Yes Can you log an issue regarding this exact matter? | 14:34:21 |
| raitobezarius | Is overmounting a tmpfs even possible in Darwin? | 14:34:39 |
| raitobezarius | Sounds like a temp workaround for cleaning the build dir | 14:34:47 |
| WeetHet | I would prefer if the daemon just did cleanup on startup/system reboot | 14:35:16 |
| emily | you do not necessarily want to run builds on tmpfs | 14:51:34 |
| emily | given how large they can be | 14:51:37 |
| emily | in fact builds being in /tmp was a blocker for /tmp on tmpfs in NixOS previously | 14:51:57 |
| WeetHet | In reply to @emilazy:matrix.org
you do not necessarily want to run builds on tmpfs You can on macOS | 14:54:20 |
| emily | you can on Linux too of course, but that doesn't mean you want to | 14:55:52 |
| emily | because build directories can get very large | 14:56:03 |
| raitobezarius | In reply to @weethet:catgirl.cloud
I would prefer if the daemon just did cleanup on startup/system reboot This should always happen, therefore, if there's any interrupted bugs, we need reports and reproducers so we can eliminate those | 16:26:40 |
|  GalaxyNova changed their profile picture. | 19:50:09 |
|  foxburu set a profile picture. | 19:56:10 |
