Run sha256sum over your release files to produce one checksum file, publish it beside the artifacts, sign it, and tell users to verify with sha256sum in check mode. A checksum catches corruption. It only resists tampering if the checksum file itself is protected.
Publisher steps
- Build in CI so the files come from a known process.
- Generate the list from inside the output directory so filenames are plain:
cd dist
sha256sum * > SHA256SUMS
- Sign the checksum file with the key or keyless method your project uses. Signing one small file is simpler than signing each artifact.
- Upload everything together: artifacts, SHA256SUMS and the signature.
- Copy the verification commands into your release notes.
User steps
The sha256sum manual describes a check option that reads checksums from files and checks them. Users run:
sha256sum --check --ignore-missing SHA256SUMS
The manual lists the ignore missing option as not failing or reporting on files that are absent, which helps when a user downloaded only one platform's file out of many. Another option prints nothing and reports success only through the exit code, which suits scripts.
Users should verify the signature of the checksum file first, then run the check.
Where the trust comes from
| Layer | What it proves |
|---|---|
| Checksum matches | The file equals what was hashed, no accidental corruption |
| Checksum file signature valid | The key holder produced that list |
| Key fingerprint matches several sources | You have the right key |
If the checksums and the binaries sit on the same page an attacker can edit, a matching hash proves very little. An attacker who replaces the file can replace the hash too. That is why the signature matters. Our post on checksum versus signature goes deeper.
Common mistakes
- Hashing with absolute paths, so users' checks fail on any other machine.
- Updating a file after publishing without regenerating and re-signing the list.
- Offering only MD5 or SHA-1. Use SHA-256 or better. See are MD5 and SHA-1 still safe for checksums.
- Forgetting to say how to verify. A checksum file nobody knows how to use does nothing.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring flags a change after release, a useful companion to checking files at download time.
Handling many platforms
Projects that ship builds for several platforms often publish one list covering every file. Users who downloaded one file then use the ignore missing option, as the manual describes, so the check does not complain about the files they never fetched. If you publish a separate list per platform instead, name each clearly and sign each. Either approach is fine. What matters is that the list is complete, that every filename in it matches the uploaded file exactly, and that the list is regenerated and re-signed whenever any artifact changes. A stale list that still verifies an old file is worse than none, because it gives false confidence.
Quick check
Is a checksum enough to trust a download?
Only if you obtained the checksum from a channel an attacker cannot also change. A signed checksum file is stronger.
Should I sign each file or the checksum list?
Either works. Signing the one list is simpler and covers every file named in it.
Sources
Last reviewed: 19 October 2026.
