Why a hash is not enough to explain software origins — Continuum Attest

A hash is useful for comparing bytes. On its own, it does not describe the commands, inputs or events that produced a file.

A digest answers a specific question

You download an archive and recompute its digest. If it matches the reference under the same algorithm and rules, you have established correspondence with that reference.

But where did the reference value come from? If a file and its reference digest are replaced together, comparison can succeed. The reliability of the channel or record carrying that reference matters alongside the calculation.

A signature protects the reference

A signature detects changes to the signed document and connects it to a key. The recipient still needs a reason to approve that key.

The signature does not tell the build’s story if the document contains only a hash. It protects exactly the signed statement, no more and no less.

Provenance adds context

Build provenance describes recorded information about production. Declared inputs, commands and results help examine why two builds produced different artifacts.

Consider two archives with the same version number but different hashes. The digest reveals the difference; provenance may help explain it by showing a changed input, step or recorded context. It can only explain what falls within the captured scope.

The receipt brings the information together

Continuum Attest records hashes and steps in a receipt that can be signed. The receipt format defines calculation and signing rules. Use the checks appropriate to that format: a generic single-file digest does not necessarily replace a digest calculated over a declared set.

To organize comparison on another machine, read Can software be verified without trusting the platform that built it?, then the offline verification guide.