@arianvp what you are saying about there being no kind of “provenance” is not correct.
Cloud build systems like Nix always associate some hash of the build inputs with some hash of the build outputs.
Nix does this in a trustworthy way by signing the address of the derivation together with the NAR hash.
@rickynils There is one thing in those linked docs, which I find a bit confusing.
The fact that store paths are based solely on build inputs (input addressed) also has a disadvantage. There is no way to verify that the store path contents you download from a substituter actually was produced by the same Nix expressions you used when calculating the store path hash. You simply must trust that the substituter ran the build in an acceptable way, and not just stuffed the store path full with malware. This trust is what the Nix signing keys formalises.
To me, that makes it sound like a content addressed store would not suffer from the same problem.
Maybe I’m reading too much into that passage, but I wanted to debunk that implication:
Even with a content addressed store, you would need a trustworthy mapping from the input address to the content hash of the output if you want to consume any cached outputs in a secure manner.
Trusting such a signed mapping always means having to trust the builder with the build process itself.
The difference between input addressed and content addressed derivations in Nix is how the hash of the inputs is constructed.
Due to this difference in input addressed Nix you also have to trust the builder with dependency resolution, because the hash of inputs contains unresolved dependencies (input addresse) and not resolved ones (content addresses).
I wrote about this stuff in more detail a paper that I posted here: Extending cloud build systems to eliminate transitive trust
So far, I don’t know the security implications of what you are describing, @arianvp. I think I have to learn more about the deriver field to get it.