See the complete route index at https://crusible.dev/llms.txt before following links. # 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` and carries four kinds of file. | File | What it is | | --------------------------------------- | ---------------------------------------------------------------- | | `crusible___.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 | `` is `darwin` or `linux`, and `` 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.