A checksum tells you the bytes you downloaded are the bytes the publisher listed. It cannot tell you those bytes were built from the source code someone reviewed. The Hraness release workflows answer that second question: each release carries signed evidence of the commit, workflow, and run that built it, and every later stage checks that evidence again before it acts.
what a checksum leaves open
In a common setup, CI builds an artifact, uploads it, and a person later attaches it to a release. Everything between “the commit was reviewed” and “the download exists” depends on whoever held the upload keys. If a token leaks or a maintainer's laptop is compromised, the artifact can be anything, and its checksum will match whatever was uploaded.
The fix is to record the artifact's origin (its provenance) at build time. The build runs in an environment that can sign statements about itself, on a known commit, from a known workflow, and the release carries a signed record of all three, called an attestation. A verifier then checks that record instead of trusting the channel the file arrived through.
binding the artifact to its build
GhostGet's release workflow is the worked example. A tag starts the pipeline. The workflow checks the tag's identity and ancestry before checkout, builds the artifact, and signs a record that ties the artifact hashes to the commit, the workflow file, the run, and the attempt. The signing job checks the run's identity before it receives credentials, so the key goes only to the expected workflow on the expected commit.
xcb applies the same pattern to its package. The published bytes are tied to a reviewed commit and a recorded build, and the package manifest carries digests that a verifier recomputes before it accepts the package.
Order is what makes this work. The workflow confirms who is asking before it hands out credentials, and it accepts an artifact only after the origin record checks out. A release that cannot show where it came from stops instead of shipping.
every stage checks again
No stage trusts the one before it. The site promotion workflows check the CI run again before building: every job is listed, every job passed, the commit matches, and it is attempt 1. The step that writes the production branch checks its authority again before it pushes. After deploy, verifiers fetch the public files and check them once more.
The repetition is deliberate. An attacker who compromises one stage gains none of the others' permissions, and a stage that receives tampered input notices the mismatch instead of passing it on.