| 2 Feb 2026 |
 raitobezarius | in general, my conclusion to do what you want securely is to use UNIX domain sockets | 20:49:08 |
| raitobezarius | if you have an UDS running locally and you can connect inside the sandbox to it to retrieve your secret key | 20:49:24 |
| raitobezarius | the server side just need to authenticate the derivation | 20:49:30 |
| raitobezarius | but if you use UDS, you receive a PID, a UID, a GID on Linux | 20:49:46 |
| raitobezarius | at that moment, you need a race-free technique to determine if that triple (PID, UID, GID) is the derivation you allow to receive a secret for | 20:50:07 |
| raitobezarius | (vague points left as exercises: how to identify a derivation, etc.) | 20:51:42 |
 Jules Lamur | That's a good point and an interesting idea. I think that more than identifying the derivation, we need a way to declare which derivation should be able to get which secret (authn vs authz in some way). I've got no idea for that part. | 21:09:17 |
| Jules Lamur | referencing the derivation that can get the secret from the CLI could work (there could be an similar interface as code with a flake.nix), eg. something like nix-build --secret sec1 ./path --allow-secret my.derivation sec1 | 21:15:05 |
| Jules Lamur | that's not a very nice UX as it requires to craft args for every derivation / every secret and to expose the derivation that can use the secret but it could work I think | 21:17:04 |
| Jules Lamur | * that's not a very nice UX as it requires to craft args for every derivation / every secret (at least for non-flake users) and to expose the derivation that can use the secret but it could work I think | 21:17:30 |
 WeetHet | One thing I don't know what to do anything about is that nix-build <tarball url> caches the tarball and there's no --refresh in nix2 so I have no idea how to force nix to redownload the tarball | 21:20:19 |
| Jules Lamur | Isn't --option tarball-ttl=0 doing that? Docs say Setting the TTL to 0 forces Lix to always check if the tarball is up to date. | 21:27:59 |
| 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 |
