| 15 Mar 2026 |
 zoë (she/her) | * is this about using secrets during the build of a derivation? cause i'd be very curious how you'd do that securely with a multi-user setup :3 | 13:11:13 |
| zoë (she/her) | the main problem i can think of is "authenticating" derivations, i.e. making sure the derivation trying to access a secret is you intended to and not some other random derivation that should not be able to read it at all. i can't really see a way of doing that without somehow prompting the user for a password of some kind during build (which would be terrible ux and a bad idea in general), because if you integrate that method of access directly into the derivation's definition, now everyone can read it and get the password for themselves | 13:18:24 |
 K900 | The solution for doing that at scale is something like SPIFFE, probably | 13:19:53 |
| zoë (she/her) | In reply to @k900:0upti.me
The solution for doing that at scale is something like SPIFFE, probably huh, that's first time of hearing about it so i might have just misread or not understood something, but i'm not sure how that'd help here, since from what i understand it's standard for creation and verification of identities, but i don't see how that squares with the fact that the nix store is public and anyone could read/duplicate the secret/identity if it's in there | 13:33:19 |
| K900 | You design your derivation in a way that the secret is never in the store | 13:33:53 |
| K900 | You read the secret from a well-known location during build time | 13:34:03 |
| K900 | So the output is in the store, but the secret itself is not | 13:34:09 |
| zoë (she/her) | right, but how do you mediate which builds can access the secret? | 13:34:31 |
| K900 | And you use SPIFFE or similar to authenticate to some sort of external secret storage, obtain the secret and inject it into the sandbox | 13:34:32 |
| K900 | The coordinator can have policies to decide that | 13:35:24 |
 KFears 🏳️⚧️ (they/them) | From what I understand, the idea is that during build time, the daemon delegates the automated auth to the user to fetch the secrets and injects them into temporary build, and purges it after the build so they don't remain in store | 13:35:40 |
| K900 | And the builder nodes authenticate the software they're running AND the exact derivation they're building | 13:35:51 |
| KFears 🏳️⚧️ (they/them) | That solves the question of "how do I not put secrets into Nix store", but it's not ACLs to Nix store, so the question of "how do I verify my private repo that I need a secret to fetch isn't world-readable in the store" | 13:36:40 |
| KFears 🏳️⚧️ (they/them) | * That solves the question of "how do I not put secrets into Nix store", but it's not ACLs to Nix store, so the question of "how do I verify my private repo that I need a secret to fetch isn't world-readable in the store" remains | 13:36:59 |
| zoë (she/her) | In reply to @k900:0upti.me
And you use SPIFFE or similar to authenticate to some sort of external secret storage, obtain the secret and inject it into the sandbox okay, but what would create the identity for the derivation?
like the one thing i could see is basically "blessing" certain derivations by signing their final eval'd form (i.e. you build a .drv, let the user then generate a signature for its file or its attrs, and then use that signature as an identity), but that would require an intermediary step /after/ the eval (and before the build) | 13:37:25 |
| KFears 🏳️⚧️ (they/them) | Basically it's fine if repo contents aren't super secret but secrets to fetch them is, from my understanding | 13:37:33 |
| K900 | Yes, that's the intent | 13:37:41 |
| K900 | There needs to be some trusted evaluator | 13:37:47 |
| K900 | That will do the evaluation and build coordination | 13:37:59 |
| K900 | And that can provide policy | 13:38:08 |
| zoë (she/her) | In reply to @kfears:matrix.org
Basically it's fine if repo contents aren't super secret but secrets to fetch them is, from my understanding right, cause you could always just encrypt the secret repo based on the fetch secret and then you're fine (e.g. like you might do with sops) | 13:38:34 |
| KFears 🏳️⚧️ (they/them) | Yeah, it's a bit awkward, but it works | 13:39:21 |
| zoë (she/her) | In reply to @k900:0upti.me
There needs to be some trusted evaluator but the evaluator also needs to trust the derivation, no? because you could always have a rogue dependency (or some other sibling if this secret-using drv is in a larger build) that wants to access the secret, so i'm struggling to see how you could ensure that the drv you're signing/making an identity for is the one you want, if there's no user interaction/verification there | 13:41:06 |
| K900 | In reply to @blokyk:matrix.org
but the evaluator also needs to trust the derivation, no? because you could always have a rogue dependency (or some other sibling if this secret-using drv is in a larger build) that wants to access the secret, so i'm struggling to see how you could ensure that the drv you're signing/making an identity for is the one you want, if there's no user interaction/verification there The evaluator inherently has to trust the things it's evaluating in some capacity | 13:41:56 |
| K900 | The sibling situation is not an issue if the daemon itself is SPIFFE aware | 13:42:42 |
| K900 | Which it would have to be | 13:42:46 |
| K900 | So your workload identity is scoped to "this exact drv file" | 13:42:59 |
| K900 | And obviously the SPIFFE authentication would also require an integrity check for the builder system itself, to assert that it's not just lying about the identity of the workload | 13:44:07 |
| zoë (she/her) | right, so you explicitely eval one part with a different/trusted evaluator and then eval the rest of the build plan with the normal nix evaluator. but that does mean, at least as far as i can tell, that you have to do eval in two steps (one trusted, one untrusted), and that you have to trust all your dependencies (most notably, the pkg repo you're pulling from) and that they won't try to get signed for nefarious reasons. for an environment like current mainstream nix where everything is bootstraped in a bunch of stages and you have a thousand dependencies, i'll admit that i have a bit of trouble with that (at least, if you're planning on not having user interaction — otherwise, you can just have the user look at the list of drvs that request an identity, which is a much easier scenario but obviously less powerful (and you're back to the same ux problem as signing)) | 13:54:05 |
| zoë (she/her) | but okay, i can see your vision now i guess | 13:54:13 |
