I often build binaries from source. Wouldn't it be cool if, whenever I built a binary from a reproducible build, I could elect to easily publish to say that I validated that the commid-id / version tag produced a binary with the correct check sum, or not via nostr?
Discussion
Bingo! Its also cool with Nix because whenever you have a derivation where the output hash is deterministic, it can just ask the cache's nostr bot if it has the hash in its store, and you know you're getting the binary you expect, as if built locally.
but if you don't build yourself, you are trusting whoever has given you the hash. getting trust assertions from a verity of sources that a version should produce that hash means that you are drastically reducing your trust in any one source.
more sources is better for sure, but the first sentence isnt necessarily true. How Nix works is the derivation has the output hash before its built. If i evaluate the build recipe and get a derivation output hash, i can then query a remote cache for that build hash.
Nix the package manager will check if the received binary matches what we expected. So youre trusting your own eval of the build, but getting the remote binary for it. Pretty neat imo.
Cool project in this vein https://nix-community.github.io/trustix/
but how do you get the derivation output hash from the build recipe?
thats a cool project. thats exactly what I was talking about with different peers doing the build and reporting back that they got the same hash. These could be nostr trust attestation events.
nix-instantiate https://nix.dev/manual/nix/2.18/command-ref/nix-instantiate
so `nix-instantiate` gives the hash of the derivation and `nix-store --realise` produces the hash of the actual binary output?
close, instantiate creates the derivation (which specifies an output hash). `nix-store --realise` builds it, producing a binary (a store path).
in the first example they use I'm guessing cigxbmvy6dzix98dxxh9b6shg7ar5bvs is the derivation hash and qhqk4n8ci095g3sdp93x7rgwyh9rdvgk is the output (binary) hash. Is that right?
In which case the derivation doesn't include the output hash or am I missing something?
https://nix.dev/manual/nix/2.18/command-ref/nix-instantiate#examples
```
nix-instantiate test.nix (instantiate)
/nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv
nix-store --realise $(nix-instantiate test.nix) (build)
...
/nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26 (output path)
ls -l /nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26
```
try `nix derivation show /nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv`
it will have an outputPath field with the binary hash. A derivation is just a json-like blob.
apparently it is not a valid store path
Ah yea its an example i guess. You could try any nix package you have defined locally, or further in the examples theres: `nix-instantiate '
yes that worked. but aren't we trusting that the author of the derivation is not including a malicious hash? this is what trustix was trying to solve or an I still missing something?
A derivation isnt downloaded, its generated locally. Then you take the output hash of the generated derivation, and look for it first locally, then remotely at binary caches. The point is that a deterministic build can be defined (the outputHash) locally and fetched remotely without fear, nix will check the received binary. Its why we call caches "substituters" in Nix, bc i can safely substitute a build output with a remote one if i know its hash. I should draw this out 😅
Trustix is more about detecting malicious builders at large. If you only rely on caches for your packages, we can compare their build outputs to each other and generate trust scores over time. It would need an ecosystem of builders to be useful.