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