| 15 Mar 2026 |
 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 |
| K900 | No, you do all of the evaluation on a trusted evaluator | 13:54:29 |
| K900 | And the builders only do building | 13:54:41 |
| K900 | The evaluator is necessarily trusted in any model, because the evaluator is what creates the identity of a workload | 13:55:14 |
| zoƫ (she/her) | so you have to trust every dependency of everything you're building? cause except if your top drv is the one that needs the secret, that seems like it just opens up more attack surface | 13:55:46 |
| K900 | No, you trust your evaluator to only allow secret access to specific workloads | 13:56:17 |
| zoƫ (she/her) | yes, i understand that the evaluator is implicitly trusted, i understand that; what i don't trust is the derivations | 13:56:29 |
| KFears& š³ļøāā§ļø (they/them) | In reply to @blokyk:matrix.org
so you have to trust every dependency of everything you're building? cause except if your top drv is the one that needs the secret, that seems like it just opens up more attack surface That's kinda already the case | 13:56:38 |
| zoƫ (she/her) | yes but how would it know that ;-; | 13:56:42 |
| K900 | And if you're worried about trusting-trust style attacks where you build a hacked curl that steals your secrets | 13:56:51 |
| K900 | Then you have bigger problems anyway | 13:56:57 |
| K900 | In reply to @blokyk:matrix.org
yes but how would it know that ;-; How would it know what? | 13:57:23 |
| zoƫ (she/her) | how would it know which drv/workloads to allow secret access to? | 13:57:52 |
| K900 | Likely via some meta attribute on the derivation | 13:58:10 |
| K900 | And probably some additional filtering on top | 13:58:19 |
| zoƫ (she/her) | well that's the case with building the software, but that's a different problem (e.g. you might be able to jail/virtualize it or whatever depending on your context); here we're trying to protect secrets on the build machine, but builds with nix don't have access to those anyway by default, so even if a derivation is written in a malicious way that tries to access /etc/shadow or /run/secrets or whatever, it won't be able to | 14:00:33 |
| zoƫ (she/her) | like yeah, it's already a (big) problem, but it's a different attack vector | 14:02:43 |
| zoƫ (she/her) | where would that come from? how do you know it's not some unrelated derivation that just skimmed the meta.identity attribute from another drv? cause i can't see anyway to do that with a user in the loop (or some kind of heuristics, but as we all know from avast&co, that'd never be reliable) ;-; | 14:03:53 |
| zoƫ (she/her) | * where would that come from? how do you know it's not some unrelated derivation that just skimmed the meta.identity attribute from another drv? cause i can't see anyway to do that with a user in the loop (or some kind of heuristics, but as we all know from avast&co, that'd never be reliable ;-;) | 14:03:58 |
| zoƫ (she/her) | * where would that come from? how do you know it's not some unrelated derivation that just skimmed the meta.identity attribute from another drv? cause i can't see anyway to do that with a user in the loop (or some kind of heuristics, but as we all know from avast&co, that'd never be reliable) ;-; | 14:04:05 |
| K900 | You can generally track down where the attribute was defined | 14:04:19 |
| K900 | And e.g. assert it's in your code repository directly | 14:04:25 |
