| 28 Jul 2025 |
raitobezarius | and you use a path only readable by root | 02:35:49 |
raitobezarius | either way, I will try to look at this once I'm less tired because I'm not exactly sure what you mean | 02:36:02 |
raitobezarius | My intent here was to increase debuggability | 02:36:08 |
raitobezarius | if I didn't get it right, this is a bug | 02:36:20 |
raitobezarius | if you intended to configure a CA file and it does not exist or is not accessible, you should get an error and unset it | 02:36:56 |
raitobezarius | is what I'm going for | 02:36:59 |
raitobezarius | because debugging why your FOD transfers files inside the build is harder | 02:37:08 |
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 |