Verify a download
What a Crusible CLI release contains, what each checksum, signature and attestation proves, and what it means when one of them does not match.
The install one-liner is one way to get the CLI. Downloading the release by hand and checking it yourself is the other, and it is equal rather than advanced: everything the one-liner relies on is published as a file anyone can inspect. This page describes those files and what each one proves.
What a release contains
A release is tagged crusible-v<version> and carries four kinds of file.
| File | What it is |
|---|---|
crusible_<version>_<os>_<arch>.tar.gz | The archive holding the binary, one per platform |
checksums.txt | A SHA-256 line for every archive in the release |
checksums.txt.bundle | A keyless signature over checksums.txt, verifiable with cosign |
crusible_..._.cdx.json | A CycloneDX software bill of materials for that build |
<os> is darwin or linux, and <arch> is amd64 or arm64. The archive
name is what the install one-liner assembles from the running machine, so the
file a hand download fetches is the same file.
Each archive also carries a build provenance attestation, stored by GitHub alongside the release rather than as a file in it.
What each check proves
The three checks answer three different questions, and none of them substitutes for another.
| Check | The question it answers |
|---|---|
The archive against checksums.txt | Is this the exact archive the release published, byte for byte |
checksums.txt against its bundle | Was that checksum list produced by the release workflow, not swapped |
| The attestation against the archive | Which workflow, in which repository, at which commit, built this |
The order matters because the guarantees stack. A checksum on its own proves
only internal consistency: an attacker who replaced the archive could replace
the checksum line beside it. The signature over checksums.txt is what makes
the checksum list itself trustworthy, and it is signed keylessly, so the
identity it records is the release workflow rather than a person holding a
key. The attestation is a separate record of where the binary came from.
When a check does not match
A checksum mismatch means the archive on disk is not the one published — a truncated download, a proxy that rewrote it, or a file from somewhere else. A mismatched archive is not the published archive, and a fresh download from the release is the ordinary cause and cure.
A signature that fails to verify is more serious: it means checksums.txt
itself is not the file the release workflow signed, and every checksum in it is
therefore unverified. An attestation that names an unexpected workflow,
repository or commit says the same thing about the binary’s origin.
What the bill of materials is for
The CycloneDX file lists the dependencies compiled into that binary, with their licences. It proves nothing about authenticity — that is the signature’s job — and exists for the reader who needs to answer whether a given library is in the binary they are about to run.