sha1sum: SHA-1 Checksums and Their Limits
sha1sum prints a SHA-1 hash and file name and verifies files with -c, the same interface as sha256sum.
SHA-1 is collision-broken, so it should not gate security decisions, but you still meet it in git object IDs and older release manifests. sha1sum reads and checks those.
What it does
sha1sum outputs HASH FILENAME and verifies a list with -c, exactly like the other coreutils sum tools. SHA-1 is fast and matches git blob/commit hashing, but collisions are practical (SHAttered), so treat a SHA-1 match as change detection or legacy compatibility, not tamper protection. Part of coreutils.
Common usage
sha1sum artifact.zip
# verify against a legacy SHA1SUMS manifest
sha1sum -c SHA1SUMS
# compare against a git-style object hash of content
printf 'blob %d\0' "$(stat -c%s f)" | cat - f | sha1sum
# quiet check for scripting
sha1sum -c --status SHA1SUMS || echo "mismatch"Options
| Flag | What it does |
|---|---|
| -c, --check | Verify files against a SHA-1 list |
| --status | Exit code only, no output |
| --quiet | Only print FAILED lines |
| --ignore-missing | Ignore listed-but-absent files |
| -b | Binary mode |
In CI
If you control the manifest, publish SHA-256 and verify with sha256sum; only fall back to sha1sum when an upstream still ships SHA-1 sums. Do not use a SHA-1 match to decide whether an artifact is safe to execute; a match proves matching, not authenticity given practical collisions.
Common errors in CI
"artifact.zip: FAILED" plus "sha1sum: WARNING: 1 computed checksum did NOT match" means content differs. "sha1sum: SHA1SUMS: no properly formatted checksum lines found" means the two-space hash name format was broken (single space, tab, or CRLF). Comparing a sha1sum value against a sha256sum value always mismatches; confirm both sides use the same algorithm.