Verify Downloaded Files with sha1sum Without Trusting SHA-1

You will finish with a checksum file that records a file's SHA-1 digest, then use it to detect an unchanged, modified or missing file. The examples use GNU coreutils 9.4, the version installed here. This is integrity checking: it can show that bytes differ, but it does not prove that a download came from a trustworthy source.

Allow about ten minutes. You need a shell, a file you can read, and a writable working directory for the checksum record. No example needs elevated privileges. Do not use sudo to make a checksum; root access does not make the result 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 40 hexadecimal characters will differ. The two spaces after the digest are part of the normal text-mode output, followed by the file name. Keep the record beside the file or in the directory where you will later run the check. The record is plain text, not a signature and not a secret.

Checkpoint: make sure the record names the exact path that exists on this machine:

$ 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. That is 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.