| 15 Mar 2026 |
 antifuchs | the nix-prefetch expression magic is really nice, if only it worked in my ci setup (or if only I could figure out why it's trying to evoke an attribute on fetchgit that doesn't exist there but exists on my dev machine) | 00:41:58 |
| antifuchs | this whole hermetics thing is very convenient, until it goes away | 00:42:23 |
 Sofie 🏳️⚧️🐾 (she/her) | K900have u found a way to have secrets in nix build yet? :3 | 06:26:49 |
| Sofie 🏳️⚧️🐾 (she/her) | * K900have u found a way to have secrets in nix builds yet? :3 | 06:27:02 |
 webtier | Funny that you're mentioning this because I was running into something like this yesterday, so while migrating I was getting a number of errors which were all pointing to my secrets.nix file not being evaluated properly (whatever the terminology is). Background is that I was handling secrets by first git adding a template secrets.nix, and then doing git update-index --assume-unchanged secrets.nix.
So quite surprisingly, native nix build system handled that well, lix was running into issues though because the changes weren't tracked and was probably seeing a bunch of nulls. Food for thought.
| 10:58:44 |
| webtier | Ofc this is just my dumb way of handling it, I could also use git secrets or something more sophisticated, but wanted to mention this edge-case. | 11:00:56 |
| Sofie 🏳️⚧️🐾 (she/her) | impure access to /run/secrets would basically be enough | 11:01:39 |
| Sofie 🏳️⚧️🐾 (she/her) | maybe an option to enable it in pure mode | 11:01:47 |
 zoë (she/her) | In reply to @sofiedotcafe:catgirl.cloud
K900have u found a way to have secrets in nix build yet? :3 is this about using secrets during the build of a derivation? cause i'd be a very curious how you do that securely with a multi-user setup :3 | 13:10:59 |
| 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 |
