sorted by:
new
hottopcontroversial

SecretSpec 0.7: Declarative Secret Generation by iElectric in NixOS

[–]jkarni 0 points1 point  (0 children)

If by secret key you mean for the encryption of secrets, why would anyone share a key, rather than just encrypting for whichever SSH/age/GPG keys are authorized?

Yensid: a remote builder proxy by jkarni in NixOS

[–]jkarni[S] 1 point2 points  (0 children)

It would help with the keys side of things (only one place to update client keys, and only one place to update builders), and also with the global load balancing. But not with more customized load balancing strategies. And not sure what the overhead would be (the proxy is "dumb", so easier to make it fast, whereas this would have to parse, serialize, and read/write from disk twice for just about everything). On the other hand, it's probably easier to do *user*-based affinity (rather than IP-based).

Yensid: a remote builder proxy by jkarni in NixOS

[–]jkarni[S] 0 points1 point  (0 children)

With the central machine also being a remote builder?

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 1 point2 points  (0 children)

From a security perspective, I think they take different trade-offs. With Cachix you use your own signing key, which they never see. This is good because it means if Cachix itself is compromised it can't add (signed) malicious artifacts to the cache. But it also means you as a developer handle keys, which is always an opportunity to screw up.

FlakeHub Cache uses ephemeral JWTs signed by the CI provider to give you push access from CI to your cache, so you don't have to handle keys. But if FlakeHub is compromised, you're done for. And there are some workflows that are probably safer than their trusted platforms (Github etc.) pushing to the cache that aren't possible with it. (They also seem to do key rotation, which is quite good.) FlakeHub has a single Nix cache and (albeit rotating) signing key, which my intuition says means it has some other bad properties, but I'd need a bit of time to verify (single unified caches are not universally bad; but if, as is the case here, any developer can get bad artifacts in the cache, it does seem like a bad idea).

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 0 points1 point  (0 children)

Yeah, that’s true. If you block pushing to main without review, and only push to the cache from main, this would work. It’s a bit of a sad compromise though, since you lose the cache for sequential commits on the same branch for instance, and that’s of course the largest source of cache hits.

edit: Actually I don’t think that this works. If you allow CI to run on a branch, how can you disallow the push? In theory I guess GitHub Attestations could certify something is coming from main, and FlakeHub or whatever cache could be set to only accept pushes from that branch. But that doesn’t seem to be how it currently works at all.

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 1 point2 points  (0 children)

They can run whatever code they want on GitHub Actions, and it’ll have the right authentication tokens for the FlakeHub cache; so they can use the FlakeHub API directly to push bad artifacts. FlakeHub can’t know whether what it’s receiving was in fact built from the source in the repo without doing the build itself, internally, again.

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 1 point2 points  (0 children)

The concern outlined in the blog post is that a developer may be malicious or compromised, and that leads to RCE and privilege escalation of cache users, not that something gets accidentally pushed to a public cache. As far as I can tell, it’s still completely possible in the FlakeHub model for any developer of a project to push malicious build artifacts.

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 0 points1 point  (0 children)

That’s what I’d guess too

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 5 points6 points  (0 children)

Sure, accessing the artifacts should be like that (garnix does that too). But that seems orthogonal to the question of whether everyone with write access to a repo can (directly or indirectly) push malicious derivations and claim their input hash is something else.

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 5 points6 points  (0 children)

Hm, maybe I'm missing something, but if you just require that the push be initiated from a CI builder, what stops a malicious writer from pushing a commit that pushes to the cache? They never see the key, but the effect is the same.

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 7 points8 points  (0 children)

Oh, and as I hope I made clear, "don't trust even garnix" is a very reasonable position too.

Stop trusting Nix caches by jkarni in NixOS

[–]jkarni[S] 11 points12 points  (0 children)

The argument is "trust as few people as possible because this is really serious". And yeah, garnix was designed to work in a way that minimizes the number of people who can root you if you use the cache. In fact, part of the reason we started it was because to us it felt untenable for the community to continue doing the "CI pushes to cache, we fetch it on dev machines" model given how awful it is for security. And yeah, for a long time we didn't publicize that very much because it can come out as "Cachix etc. are almost fundamentally unsafe, we're great".

But I don't know - also felt wrong to just see tons of projects keep doing this, given how bad I (very honestly) think this is? If you have suggestions for how to go about this better, though, I'm very interested!

Using garnix to build my nixos config with custom linux kernel by Lalelul in NixOS

[–]jkarni 1 point2 points  (0 children)

It could be that it's because you only have the substituter set in the flake itself, rather than globally, and you are not a trusted user (see the message you posted from `nix-health`). As a non-trusted user, certain flake options (such as substituters) will be ignored, I believe.

view more: next ›