Downloading a release from a project page is only part of the job. Before installing it, check that the file arrived intact and that it really came from a source you trust. A checksum can detect changes to a download, while a digital signature can help establish who published the checksum or release. Neither check is useful if you trust the wrong source or skip a step.
This tutorial shows how to choose a trusted release page, verify a downloaded file on Linux, macOS, or Windows, and understand what the results do—and do not—prove.
Key takeaways
- Download releases from the project's official website, repository, or documented release channel.
- A checksum comparison verifies that two files have the same contents; by itself, it does not prove who created either file.
- A valid digital signature can authenticate signed data, provided you have independently verified the signing key.
- Verify the exact file you plan to install, for the correct version and platform, before running or installing it.
- A package manager's signature verification can be safer and easier than manually downloading an installer, when the project or operating system provides a trusted package source.
Choose a trusted release source
Start from a project website or repository that you already have reason to trust. Follow its documentation to the release page; do not rely on an unfamiliar search result, a reposted download, or a link in an unsolicited message. Check that the project name and domain are correct, and confirm that the release is the version you intended to download.
Before downloading, identify:
- The version number and whether it is a stable release, preview, or development build.
- The correct operating system and processor architecture, such as x86-64 or ARM64.
- The exact installer or archive filename.
- Whether the project publishes a checksum file, a detached signature, or both—and what those files cover.
A browser connection using HTTPS protects the connection to the site, but it does not establish that a particular file was created by the intended developer. A compromised website or account could serve a malicious file and matching checksum. That is why trusted release channels and signature verification matter.
What checksum verification proves
A cryptographic hash function produces a fixed-length value from a file's contents. A SHA-256 checksum, for example, changes if the file changes. To verify a download, calculate its checksum and compare it with the expected value published by the project.
If the values match, the downloaded file has the same contents as the file represented by that expected checksum, assuming the hash function and tools are implemented correctly. This is useful for detecting an incomplete, corrupted, or altered download.
But a checksum alone does not establish authenticity. If an attacker can replace both the download and the checksum on the same compromised page, the values can still match. For stronger assurance, verify a digital signature over the release file or over the checksum manifest, using a signing key whose identity you confirmed independently.
Verify a checksum on Linux, macOS, or Windows
First, download the release file and its checksum information from the trusted release page. Keep the original filename and avoid opening or installing the file until verification is complete. The examples below use app-1.2.3-linux-x86_64.tar.gz and SHA256SUMS as illustrative names; substitute the actual names from the release.
Linux
To calculate the file's SHA-256 value:
sha256sum app-1.2.3-linux-x86_64.tar.gz
Compare the resulting hexadecimal value with the SHA-256 value shown on the trusted release page. If the project provides a checksum manifest in the standard format and its entry names the downloaded file, you can check it with:
sha256sum -c SHA256SUMS
Run that command in the directory containing the manifest and the file, or make sure the paths in the manifest resolve correctly. A FAILED result means the file does not match that entry; do not install it. A missing-file error usually means the filename or path in the manifest does not match your download.
macOS
Use shasum to calculate SHA-256:
shasum -a 256 app-1.2.3-macos-arm64.dmg
Compare the result with the expected value from the trusted release information. If the project supplies a compatible checksum manifest, you can check its entries with:
shasum -a 256 -c SHA256SUMS
As on Linux, check that the manifest entry refers to the file you actually downloaded. If the command reports that a file cannot be opened, confirm the path and filename rather than assuming the verification passed.
Windows PowerShell
Calculate the SHA-256 value with the built-in Get-FileHash command:
Get-FileHash .\app-1.2.3-windows-x64.zip -Algorithm SHA256
Compare the Hash value with the SHA-256 value published by the project. PowerShell prints the hash in hexadecimal; compare the complete value, not just its beginning. If you are comparing manually, ensure there are no missing or extra characters.
These commands calculate or check checksums; they do not verify a publisher's identity. A matching value is only as trustworthy as the source of the expected value.
Verify a digital signature
A digital signature is created with a private signing key and checked with the corresponding public key. When the signature is valid, it shows that the signed data has not changed since it was signed by whoever controls that private key. To connect that key to the intended project, you must also establish that the public key really belongs to the project.
Projects may sign the release file itself or sign a checksum manifest. A common workflow is to verify a signed checksum manifest, then use the verified manifest to check the download. For example, if the project provides SHA256SUMS and a detached signature named SHA256SUMS.asc, and you have installed GnuPG from a trusted source, run:
gpg --verify SHA256SUMS.asc SHA256SUMS
The same GnuPG command is available on Linux, macOS, and Windows when GnuPG is installed. For a differently named signature file, substitute its actual name. Some projects use another signature format or document a different verification procedure; follow the project's official instructions rather than assuming every signature file uses the same format.
A message that a signature is mathematically valid is not, by itself, proof that the key belongs to the project. Before relying on the result:
- Find the signing key fingerprint in an official project channel, such as its security or release documentation.
- Confirm that fingerprint through a second, independent trusted channel when possible. Do not treat a keyserver search result or a key bundled beside the download as independent confirmation.
- Compare the complete fingerprint, not only a short key ID.
- Check GnuPG's output to identify the signing key and determine whether the signature is valid. Warnings that the key is untrusted or its identity is unverified are relevant; do not ignore them.
- If the signature is invalid, the signed file is missing, or the key identity cannot be established, stop and consult the project's official instructions or maintainers before installing.
A signature proves control of a signing key, not that the software is harmless, carefully reviewed, or free from vulnerabilities. A project or signing key can also be compromised. Signature verification is one part of a secure installation process, not a guarantee of safety.
A practical verification workflow
Use this sequence for a manually downloaded release:
- Navigate from a trusted starting point. Use the project's known website or repository and follow its documented release link.
- Select the right release. Confirm the version, release status, operating system, architecture, and filename.
- Download the artifact and verification files. Save them in a working directory, but do not run the artifact.
- Verify the signing key, if a signature is provided. Confirm the full fingerprint through trusted project documentation and, where feasible, an independent channel.
- Verify the signature. Follow the project's documented command and confirm that the signature is valid for the exact artifact or checksum manifest you received.
- Verify the checksum. Calculate the downloaded file's hash or check it against the now-verified manifest. Confirm that the result matches and that the manifest entry names the intended file.
- Install only after checks pass. If any result is unclear or fails, delete or quarantine the download and obtain guidance from the project through a trusted channel.
When your operating system or project offers a package manager with authenticated repositories, prefer the documented package-management workflow where appropriate. Package managers can verify signed repository metadata and packages, but their protection depends on correct repository configuration, trusted signing keys, and a secure system. Do not add an unfamiliar repository just to obtain a package without evaluating its source and trust settings.
Common mistakes and troubleshooting
Treating a matching checksum as proof of the publisher
A matching checksum only connects your file to the expected checksum value. If that value came from the same compromised source as the download, it may not provide meaningful publisher authentication. Verify a signature or use a trusted distribution channel when available.
Comparing the wrong files
Releases often include multiple architectures, operating systems, and packaging formats. A checksum for an installer will not match an archive, even if both are for the same version. Match the exact filename and release asset.
Verifying a manifest but not the download
A valid signature on SHA256SUMS authenticates that manifest, not every file that might be in the release. Check that the manifest contains the intended artifact and then verify that artifact against its entry.
Ignoring paths and filenames
Checksum tools can report a missing file when a manifest refers to a different directory or filename. Keep the filenames intact where possible, inspect the manifest entry, and verify the exact downloaded file. Do not rename files in a way that makes it unclear which entry is being checked.
Accepting a key because it came with the download
A public key distributed alongside a release can be replaced along with the release. Confirm the key's full fingerprint using official project information and, if possible, an independent channel.
Installing after an error or warning
A failed checksum, invalid signature, unknown signing key, or unresolved trust warning is not a successful verification. Stop and investigate rather than retrying installation. Re-download only from a trusted source, and contact the project through an independently confirmed channel if the issue persists.
Conclusion
To verify downloaded software checksum values, calculate the hash of the exact release file and compare it with a value obtained from a trusted source. For stronger publisher authentication, verify a digital signature and independently confirm the signing key's identity. These checks reduce the risk of installing a corrupted or substituted download, but they cannot guarantee that the software itself is safe. Use the project's documented release process, verify before installation, and treat failed or ambiguous checks as a reason to stop.