| 2 Feb 2026 |
 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 |
| raitobezarius | but that CD system would have done the eval for you | 22:16:11 |
| raitobezarius | introducing the concept of secrets into nix that way makes me nervous but not sure i have clear arguments on why | 22:16:43 |
| raitobezarius | also i still have this feeling that it shouldn't be the invocation's role to tell what is allowed to access a secret or not, because if you are the attacker and you can control that invocation you can simply authorize your own hacked derivation to access the secrets | 22:17:47 |
 embr | In reply to @raitobezarius:matrix.org
introducing the concept of secrets into nix that way makes me nervous but not sure i have clear arguments on why (my gut reaction to this is "don't put secrets in the nix store" is nice and straightforward, making it more complicated feels like it could easily become a footgun that one day leads to disaster) | 22:18:11 |
| raitobezarius | yeah but here it's not a trivial "putting secrets in the nix store" | 22:18:30 |
| raitobezarius | if you have a socket in the sandbox and you use it to sign a binary and put a signed binary in the store | 22:18:39 |
| raitobezarius | you are not putting secrets in the nix store | 22:18:44 |
| raitobezarius | this property is held | 22:18:48 |
| raitobezarius | (the socket sandbox can be backed by a PKCS#11 over UDS signer for example) | 22:19:08 |
| raitobezarius | obviously if people starts pulling key material in the sandbox that way and accidentally write them in $out | 22:19:27 |
| raitobezarius | mama mia | 22:19:28 |
| raitobezarius | is this how we make UEFI test keys go in production builds? | 22:19:41 |
 WeetHet | Oh, I see, thanks | 22:54:36 |
| Jules Lamur | oh that's right, I did not think of that 👍️ | 22:54:47 |
| Jules Lamur | Not addressing your point directly, but even if the invocation passes secrets' "references" (ie. files in my previous examples), that does not prevent the actual secrets store from having authorization. For files it's the kernel doing its things, but you could imagine having secrets references with other "fetchers" for example nix-build --secret sec1 bao:foo/bar/baz or something like that, and openbao does it's job checking that the user running the command has access to the secret. | 23:00:27 |
| Jules Lamur | If the user is compromised and can run arbitrary commands it's already game over, even if they can't map secrets to derivations? | 23:01:59 |
| Jules Lamur | Also, would it be a problem that, by design, these derivations cannot be reproducible? A lot of the nixpkgs ones are not so I guess that would be only a "philosophical problem"? | 23:10:27 |
| Jules Lamur | (Reproducible / determinist in the sense that even with the same signature key, the signed binary differs) | 23:14:23 |
| raitobezarius | the reproducible problem can be fixed by extending the Nix model | 23:14:31 |
| raitobezarius | for example, there could be some sort of special input-addressed derivations which are deterministic modulo verification of the artifacts with a certain public key that needs to be declared | 23:15:04 |
| raitobezarius | * for example, there could be some sort of special input-addressed derivations which are deterministic modulo verification of the artifacts with a certain public key that needs to be declared in the drv | 23:15:07 |
| raitobezarius | so the outputs is IA + mod public key verification | 23:15:17 |
| Jules Lamur | that would be nice | 23:15:34 |
