| 2 Feb 2026 |
 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 |
| 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 |
