Following up on my post Content-addressed Nix − call for testers - #206 by gador
is there a binary cache available that supports CA derivations?
1 Like
The original posting mentions cache.ngi0.nixos.org if that’s what you mean.
If you mean one to self host, I’m not sure.
Yes I ment self-hosting…how does our cache instance gets served? This should obviously be able to serve the realisations endpoint…
I am not aware of any cache that’s being (self)hosted. The ngi0 cache was down last I checked. I’d like to host a cache but I’m not promising anything, and it will at least be half a year before I can start with that, I suspect.
I have a local cache running on a self-hosted S3 (minio) which is supplied by hydra with the current PR https://github.com/NixOS/hydra/pull/875
This supplies the realisations endpoint and seems to work pretty well for my ca-derivations.
Is my understanding correct that a public ca-derivation cache will not necessarily need a (trusted) signingKey, because the store paths are actually verifiable?
If I would supply a S3 cache for e.g. nixos-small, could other users benefit from this without inherently trusting me?
1 Like
Issues · NixOS/nix · GitHub Note that I’ve started to write some issues for what is needed before CA derivations can be rolled out to hydra.nixos.org and then stabilized.
My basic litmus test is I don’t want to be put junk in the cache. If we “client” code doesn’t work ideally for whatever reason, that can be fixed relatively painlessly, but if junk gets uploaded, that will haunt us for longer.
The good thing is that its only a few things left before I am pretty happy with the cache format, and the precision of the build trace map claims being made therein.
9 Likes
Content-addressed Nix doesn’t remove the need for trust: you still need to trust who-ever is telling you ‘this output corresponds to this build specification’.
In traditional Nix, you could calculate the store path from the build specification yourself (no need for trust), and then you had to trust the cache that the output it sends you actually corresponds to that specification (by trusting/checking the signature).
With Content-addressed Nix, you no longer have to trust the cache that the output it sends you corresponds to the path you asked for: as it’s content-addressed, you can check it yourself. However, you can no longer calculate that store path yourself: you use the realisations endpoint for that. So instead of trusting the cache ‘itself’, you now have to trust the realisations endpoint (by trusting/checking the signatures on its responses).
In theory supplying your S3 cache might be useful for others, but we’d still need a way to share trusted(/signed?) realisations.
(this is mentioned in the RFC in rfcs/rfcs/0062-content-addressed-paths.md at 25c3f524631000b851375e7b96223a56e71cc0e2 · NixOS/rfcs · GitHub)
9 Likes