| 2 Feb 2026 |
 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 |
| raitobezarius | some steps in the CD where you eval your stuff, get the drvpath associated to the attribute you want, send it to openbao for ACL updates | 22:08:34 |
| raitobezarius | but basically it's also trusting the eval pipeline or something | 22:08:55 |
| Jules Lamur | the other channel I proposed was the CLI flags --secret, --allow-secret (or something at inputs/outputs level in flakes) :) One could also image a secrets.nix passed to the cli, eg. nix-build --secrets ./secrets.nix | 22:13:43 |
| Jules Lamur | I have to admit that this is probably the best counter-argument to implementing any of that 😅 | 22:14:59 |
| raitobezarius | but almost everything ends up trusting the eval pipeline if there's no clear architecture | 22:15:40 |
| raitobezarius | including the solution where you sign off the sandbox | 22:15:47 |
| raitobezarius | because somewhere you push artifacts in some cache or S3 and you get them back somewhere else by evaluating what you need or querying a CD system with jobs and what not | 22:16:04 |
