| 2 Feb 2026 |
 WeetHet | Oh, nice, I didn't know about that one | 21:28:22 |
 Jules Lamur | It does check the Etag before redownloading btw so check the docs if that's not what you want :) | 21:29:14 |
| WeetHet | If I'm using nix-run to run a package from a nixpkgs PR and someone force pushes I wanna have a way to reuse the same url and not go fishing for a specific revision basically | 21:31:12 |
| WeetHet | Imma add a --refresh option in the next nix-run release if I don't forget | 21:32:04 |
| Jules Lamur | (after testing it a bit, I'm not sure that this option works as expected :/) | 21:34:13 |
| WeetHet | * Imma add a --refresh convenience option in the next nix-run release if I don't forget | 21:34:25 |
| Jules Lamur | without network and a cached tarball nix3 with --refresh fails: warning: error: unable to download [...] but nix2 with the option tarball-ttl does not 🤷 | 21:35:36 |
| Jules Lamur | * without network and a cached tarball, nix3 with --refresh fails: warning: error: unable to download [...] but nix2 with the option tarball-ttl does not 🤷 | 21:35:45 |
| Jules Lamur | * without network and a cached tarball, nix3 with --refresh fails warns: warning: error: unable to download [...] but nix2 with the option tarball-ttl does not 🤷
(correction: it's a just a warning, maybe it's just not logged with nix2?)
| 21:38:14 |
| Jules Lamur | * (after testing it a bit, I'm not sure that this option works as expected :/) | 21:43:04 |
| Jules Lamur | * without network and a cached tarball, nix3 with --refresh fails warns: warning: error: unable to download [...] but nix2 with the option tarball-ttl does not 🤷
(correction: it's a just a warning, maybe it's just not logged with nix2?)
| 21:43:14 |
| Jules Lamur | ^ PEBCAK, it does work, sorry for the noise. And WeetHet you probably want to set these other options to 0 too, I'm not sure: narinfo-cache-negative-ttl and narinfo-cache-positive-ttl. cf. https://git.lix.systems/lix-project/lix/src/commit/3d77ee8d94b3e8370bd85cd1430dd14dd475c3a7/lix/nix/main.cc#L646-L650 | 21:46:19 |
 raitobezarius | my feeling is that you should never be able to ascribe the ACLs on the CLI or inside the drv params | 21:56:34 |
| raitobezarius | the server should identify the derivation and consult its own ACL to authorize providing the secret or not | 21:56:47 |
| raitobezarius | but yeah a derivation may need a system feature like requiredSystemFeatures = [ "have-secret-X" ]; | 21:56:59 |
| raitobezarius | so that the scheduler schedule it on a system with a extra-sandbox-path to the right UDS | 21:57:11 |
| raitobezarius | a trivial impl of the secret server could be an OpenBao with a "Nix extension" that pops that UDS and try to ask the local Nix daemon "is this (PID, UID, GID) the drv X that it is claiming it is?", if so, it provides the secrets | 21:58:49 |
| raitobezarius | then in OpenBao, you can create policies/entities tied to these derivations | 21:59:10 |
| raitobezarius | a couple of golang that you love so much :P | 21:59:28 |
| raitobezarius | * a couple of golang lines that you love so much :P | 21:59:39 |
| Jules Lamur | I think that the problem then is what information exactly can OpenBao use to identify that the drv is really the one it pretends to be? Even if the nix daemon responded with the full derivation text, how can you securely identify that the derivation should have access to that secret and that it's not another one (eg. a compromised third party dependency or even an unrelated project) trying to steal that? | 22:03:29 |
| raitobezarius | well going from all builds can access to my secrets to "only the builds i care about" can access my secrets needs to solve that problem anyway | 22:04:26 |
| raitobezarius | if you go like *-$pname-$version is allowed to access to sb-signing-key, then, any derivation that names itself pname = $pname; version = $version; can hijack the secret, yes | 22:04:55 |
| raitobezarius | but the problem is somewhat inherent to obtaining secrets inside sandboxes i feel like | 22:05:30 |
| raitobezarius | instead, if you have channel scripts / release engineering scripts that calls into the attribute you care about, build it and then take the signing outside the sandbox, this problem is alleviated | 22:05:55 |
| Jules Lamur | It might be okay-ish to accept that for fetchGit or similar functions because you can check the URL and match on that. But (to refer to my previous example) in the case of signing binaries/UKIs you can't accept that risk I guess? | 22:06:05 |
| raitobezarius | yeah i don't know how to make that secure for signing binaries | 22:07:39 |
| raitobezarius | you either need a way to prevent attackers to schedule builds to get themselves whatever they want signed | 22:08:00 |
| raitobezarius | or | 22:08:01 |
| raitobezarius | you need another channel to register the exact drvhash of what is allowed to be signed | 22:08:09 |
