| 28 Jul 2025 |
 EsperLily [she/her] | the code that installs the certs calls pathAccessible(settings.caFile) first, that's the thing that I said needs to be pathAccessible(settings.caFile, true). But if that returns false, the code then checks if pathExists(settings.caFile) in order to throw a warning that the path exists but is inaccessible. Unfortunately if the path isn't accessible because of a permissions problem, then the pathExists call will throw an exception. So that pathExists should be pathAccessible(settings.caFile, false) (or pathAccessible(settings.caFile)), so that way a permissions problem just turns into false | 02:37:35 |
| EsperLily [she/her] | oops that was supposed to be a replyto this | 02:37:50 |
| EsperLily [she/her] | * oops that was supposed to be a reply to this | 02:37:54 |
 raitobezarius | In reply to @esperlily:matrix.org
the code that installs the certs calls pathAccessible(settings.caFile) first, that's the thing that I said needs to be pathAccessible(settings.caFile, true). But if that returns false, the code then checks if pathExists(settings.caFile) in order to throw a warning that the path exists but is inaccessible. Unfortunately if the path isn't accessible because of a permissions problem, then the pathExists call will throw an exception. So that pathExists should be pathAccessible(settings.caFile, false) (or pathAccessible(settings.caFile)), so that way a permissions problem just turns into false well spotted | 02:38:05 |
| raitobezarius | this is also a problem for other code paths | 02:38:10 |
| raitobezarius | thank you :) | 02:38:13 |
| EsperLily [she/her] | it bothers me how many of our filesystem helpers just happily throw exceptions without necessarily being obvious from the function call that it's going to do that. In many cases yeah a permissions problem should turn into a hard error, but in other cases it shouldn't, and because this is done with exceptions it's a silent problem and too easy to miss | 02:40:30 |
| raitobezarius | i mean the technical debt in this codebase is what it is | 02:41:28 |
| raitobezarius | my biggest nightmares right now are really the StorePath class | 02:41:55 |
| raitobezarius | and how it goes from StorePath to string | 02:42:01 |
| raitobezarius | and what a disaster it is wrt to chroot, not chroot, sandbox, not sandbox, linux, not linux, etc. | 02:42:12 |
| raitobezarius | and I think I'm going to tackle this at some point | 02:42:29 |
| EsperLily [she/her] | that sounds like a mess | 02:42:47 |
 jade_ | i think i found a bug in the nix store delete error message related to said stringification. headache inducing. | 02:42:57 |
| raitobezarius | yeah | 02:43:09 |
| raitobezarius | repairing chroot stores meant that i had to sprinkle a bunch of toRealPath(s) while not being certain all the time | 02:43:21 |
| raitobezarius | and we have APIs that accepts only logical paths | 02:43:27 |
| raitobezarius | so if you give it a physical path, it will err out | 02:43:40 |
| raitobezarius | and it trickles down to the CLI | 02:43:48 |
| jade_ | also what exactly CanonPath means or what constructing one means is Non Obvious | 02:43:52 |
| raitobezarius | so sometimes you need to do nix $COMMAND $PHYSICAL_PATH --store $CHROOT_STORE or substitute $PHYSICAL_PATH for $LOGICAL_PATH | 02:44:15 |
| raitobezarius | and there's absolutely NO documentation on which command requires what | 02:44:25 |
| raitobezarius | but this needs to stop | 02:44:39 |
| raitobezarius | we need to stop having to use toRealPath manually | 02:44:43 |
| jade_ | yessss | 02:44:47 |
| raitobezarius | type safety needs to fix that | 02:44:49 |
| jade_ | also --store throwing an assert for a relative path. headache! | 02:45:09 |
| jade_ | also "chroot stores" are a misnomer because they work on macOS but just cant do builds | 02:45:26 |
| raitobezarius | the concept of chroot stores as a duplicated piece of code should die | 02:45:31 |
| jade_ | yes | 02:45:37 |
