Back

@ivan

This is true for every normal binary package repo. But where is the attac vector for the #nixos #nix binary cache?

SHA256 collisions are very rare, expensive and leave a large trail of evidence. Exposes and burns after first use everyone involved. Forever.

Individual targeted checksums would require control of your source code repo as well. If this is the case you are equally f*** with or without using a binary cache at all.

So, yes, stay away from toxic corporate controlled flakes, git repos, channel, …

Ask every contributor to sign his project repo git commits & tags. Then it’s easy to pin down and publicly burn bad actors.

Pin down the public community cache public keys yourself. Do not trust upstream defaults. Verify via different communication channel.

example.nix

nix.trusted-public-keys = [

"nixpkgs-unfree.cachix.org-1: hqvoInulhbV4nJ9yJOEr+4wxhDV4xq2d1DK7S6Nj6rs="

"nix-community.cachix.org-1: mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs="

"cache.nixos.org-1: 6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY="
];

https://github.com/paepckehh/nixos/blob/main/configuration.nix

@paepcke
> But where is the attac vector for the #nixos #nix binary cache?

Hashes are only for source (or fixed) outputs. Nix derivations are *input* addressed (by default, I’m ignoring content-addressed derivations which are not stable as of today) not *output* addressed

When you try to `nix build nixpkgs#hello` you have no idea of what the output should look like (besides build the package yourself and compare your result to that of others doing the build too à la trustix)

NORMALLY building that package should follow its regular build instructions (and use its *input* addressed dependencies). But if I can push to a cache, nothing stops me from creating a malicious NAR that has a backdoored result. There’s nothing that guarantees a particular NAR is the result of building via the build instructions in the actual derivation file. That’s why Nix has a model for signing builds and trusting particular substituters: you have to trust they build the package with the actual instructions and didn’t do something malicious

@ivan

The nixstore digest itself declares the (claimed) input parameters only, but fails to feed the SRI (Subresource Integrity) part for the actual binaries / folder content into the hasher loop?

Thats bad, since pinning down the exact input parameter should lead to 100% bit-by-bit reproducible binaries with every modern toolchain.

Without, the executables trust relies completely on the AppAmor hashes only.

Time for a code review and some discussion in the RFC section I guess!?

At least, if anyone can reproduce a single valid >signed< bad package, the company, business model and attack model is burned.

Maybe we need some x509 CT (certificate transparency logs) equivalent at some point.

@paepcke
> At least, if anyone can reproduce a single valid >signed< bad package, the company, business model and attack model is burned.

Signing a malicious package with *someone else’s* key is going to be difficult (unless you have the means to break the current cryptographic algorithms)

But if an attacker convinces you to trust *a key they control* you are toast. This is why you need to be careful with whose substituter keys you mark as trusted

@zstg @ivan probably determinant systems. There was some drama awhile back over Nixcon sponsors and DetSys was tangentially related IIRC. I’m not the best person to talk about this as I tried to ignore most of it. OP probably has better information. That being said, DetSys does maintain a fork of Nix that, IMO, reeks of EEE.