Verify File Integrity with sha1sum

sha1sum records a file's SHA-1 digest so you can tell later whether it changed, went missing, or was corrupted in transit. This is integrity checking, not authentication: it can show that bytes differ, but it does not prove a download came from a trustworthy source. The examples use GNU coreutils 9.4, the version installed here.

• Time. About ten minutes.
• Needs. A shell, a file you can read, and a writable working directory for the checksum record. No example needs elevated privileges.
• Skip sudo. Root access does not make a checksum more trustworthy.

1. Check the installed command

Confirm which implementation will run and record its version. This is a read-only checkpoint:

$ command -v sha1sum
/usr/bin/sha1sum
$ sha1sum --version | head -n 1
sha1sum (GNU coreutils) 9.4

The command prints a 160-bit digest. With no file argument, or with -, it reads standard input. With a file argument, it reads that file and leaves it unchanged.

2. Create a checksum record

Choose a source file and write the command's output to a separate record. Replace the example path with the file you actually received:

$ sha1sum /path/to/download.tar.gz > download.tar.gz.sha1
$ cat download.tar.gz.sha1
0a3ee294945e52d77cb46600e19bd86bb1f67c07  /path/to/download.tar.gz

• Your digest will differ. The 40 hexadecimal characters are unique to your file.
• Two spaces are normal. They separate the digest from the file name in text-mode output.
• Keep the record beside the file, or in the directory where you will later run the check. It is plain text, not a signature and not a secret.

$ test -r /path/to/download.tar.gz && echo "source is readable"
source is readable
$ test -s download.tar.gz.sha1 && echo "checksum record is non-empty"
checksum record is non-empty

3. Verify an unchanged file

Use --check, or its short form -c, with the checksum record:

$ sha1sum --check download.tar.gz.sha1
/path/to/download.tar.gz: OK

An OK line means the digest calculated from the named file matches the digest in the record. The command returns status zero when the checks pass. Check the status explicitly when a script must make a decision:

$ sha1sum --check --status download.tar.gz.sha1
$ printf 'verification status: %s\n' "$?"
verification status: 0

--status suppresses normal output, so silence is expected. It is useful for automation, but it is easy to mistake silence for a command that did not run. Use the ordinary form while investigating a problem.

4. Understand a mismatch

To see the failure shape, change the file after recording its digest. Do not perform this test against the only copy of valuable data. A real mismatch commonly means an incomplete download, the wrong file, a later update, or tampering:

$ sha1sum --check download.tar.gz.sha1
/path/to/download.tar.gz: FAILED
sha1sum: WARNING: 1 computed checksum did NOT match
$ printf 'verification status: %s\n' "$?"
verification status: 1

The exact warning count depends on the record. Re-download or restore the file from a trusted local backup, then verify again. Do not edit the digest in the record to make a failed check pass. If the publisher supplied a detached signature or a stronger verification method, use that instead.

5. Deal with missing files and malformed records

If the path in the record does not exist, the normal check reports the problem and returns non-zero:

$ sha1sum --check download.tar.gz.sha1
sha1sum: /path/to/download.tar.gz: No such file or directory
sha1sum: WARNING: 1 listed file could not be read

Restore the file or correct the record's path only when you have established that it refers to the intended file. For a batch record where missing files should be skipped, --ignore-missing suppresses status for absent paths, a policy choice, not proof that the whole set passed. A backup check should normally leave this option out.

When accepting records from another system, add --warn to report improperly formatted lines. Add --strict when malformed lines must make the command fail. These options matter only with --check; they do not change how a new digest is calculated.

6. Avoid the security boundary trap

The manual explicitly warns against using SHA-1 for security-related purposes. SHA-1 collision attacks mean that a checksum supplied through an untrusted channel is not a strong authenticity mechanism. A checksum copied from the same compromised download page does not establish provenance.

Use sha1sum when you are required to reproduce a legacy checksum or compare content with an existing SHA-1 record. For new security-sensitive workflows, use a stronger, authenticated process. GNU coreutils also provides sha256sum, sha512sum and b2sum, but a bare SHA-256 file downloaded from the same untrusted source still needs an independent trust path.

There is no undo command for checksum calculation or verification: these operations only read the source and write the destination you name with shell redirection. The one destructive trap is the redirection itself: > truncates an existing checksum record before sha1sum starts. Use a new name, or preserve the old record before deliberately replacing it.