Verify a download: sha256sum -c, then the signature

sha256sum -c SHA256SUMS checks every file listed in the checksum file and prints OK or FAILED for each — no comparing hex strings by eye. That proves the download arrived intact. It does not prove the release is genuine: for that you verify the signature on the checksum file itself.

1. Check everything you downloaded

$ clai verify the checksums of the downloaded files→ sha256sum -c SHA256SUMSapp-1.2.0-darwin-arm64.tar.gz: OKapp-1.2.0-linux-amd64.tar.gz: OKapp-1.2.0-linux-arm64.tar.gz: OK

SHA256SUMS is a plain text file of "hash, two spaces, filename" lines that projects publish next to a release. -c does the comparing itself, which is the entire point.

2. You only downloaded one of the files

$ clai verify only the file I actually have→ sha256sum -c --ignore-missing SHA256SUMSapp-1.2.0-linux-amd64.tar.gz: OK

Without --ignore-missing the check complains about every absent file with FAILED open or read and exits 1, even though your file is fine. That is the most common reason people think verification failed.

3. What a real failure looks like

$ clai verify the file after a broken download→ sha256sum -c --ignore-missing SHA256SUMSapp-1.2.0-linux-amd64.tar.gz: FAILEDsha256sum: WARNING: 1 computed checksum did NOT matchsha256sum: SHA256SUMS: no file was verified

Verified by flipping a single byte in the archive. The exit code is 1, which is what a script should look at. FAILED means "wrong file"; FAILED open or read means "no file" — different problems.

4. One hash, no checksum file

$ clai compare the file against the hash from the download page→ echo "<hash>  app-1.2.0-linux-arm64.tar.gz" | sha256sum -c -app-1.2.0-linux-arm64.tar.gz: OK

The two spaces between hash and filename are part of the format, not typography. This is how you check when the site publishes a single hash instead of a sums file.

5. The signature matters more than the hash

$ clai verify the signature of the checksum file→ gpg --verify SHA256SUMS.asc SHA256SUMSgpg: Signature made Thu Aug 27 23:09:38 2026 +07gpg:                using EDDSA key CDDC16ABE7FBF699F0CA9D6C7CA6166B006AB9B0gpg: Good signature from "App Releases <[email protected]>" [ultimate]

This is the part most guides skip. A hash proves the bytes arrived whole, not that the release came from its author: an attacker who replaces both the archive and SHA256SUMS gets matching hashes. The signature does not survive that — change one character in the checksum file and gpg answers BAD signature from "App Releases <releases@example.com>", as tested.

6. When you don't have the key

$ clai verify the signature without the project key→ gpg --verify SHA256SUMS.asc SHA256SUMSgpg: Signature made Thu Aug 27 23:09:38 2026 +07gpg:                using EDDSA key CDDC16ABE7FBF699F0CA9D6C7CA6166B006AB9B0gpg: Can't check signature: No public key

That is not "bad signature", it is "nothing to check it with". Fetch the key with gpg --recv-keys <fingerprint> — and take the fingerprint from somewhere other than the page you downloaded the file from, or the check is just verifying itself.

Gotchas

• FAILED and FAILED open or read are different problems. The first means the file is corrupt or swapped, the second means it isn't in the directory. --ignore-missing is the answer to the second one only.
• A matching hash is not authenticity. Hashes protect against a truncated download, not against a substituted release. Authenticity needs a signed checksum file plus a key obtained independently of the download page.
• The line format is strict. Exactly two spaces between hash and filename; a single space or a tab gets you no properly formatted checksum lines found.

Related questions

How is sha256sum different from md5sum? The algorithm. MD5 has been broken for collision attacks for years, so it can't establish authenticity; it still detects a corrupted download, but there is no reason not to use SHA-256.

How do I check a hash on Windows? certutil -hashfile app.tar.gz SHA256 in cmd, or Get-FileHash in PowerShell. Different formatting, same value.

What do I do when checksums don't match? Download again — a truncated transfer is the usual cause. If it fails twice, switch mirrors and verify the signature before trusting anything.

See also

• Resume an interrupted download with curl
• Split a large file into parts, and put it back together
• Extract any archive

CliAI writes the verification line — including the flag for the file you actually downloaded — and shows it before it runs. Install it in one line.