Verify Software Downloads with Checksum Verification

Verify Software Downloads with Checksum Verification

Every downloaded installer, executable, or archive carries a cryptographic fingerprint that most people ignore. Checking that fingerprint against the publisher's published checksum takes seconds and confirms the file you have is exactly the file they released, byte for byte, with no modifications introduced during transit or storage.

How supply chain attacks target software distribution

Traditional security advice tells you to download software only from official sites. That advice is not enough. A supply chain attack targets the delivery mechanism itself: attackers compromise the build pipeline, download server, or mirror infrastructure of a legitimate project, then replace the authentic binary with a modified version containing malicious functionality. The file you download comes from the right place, has the right name, and passes every superficial check.

Three documented incidents show how this plays out at scale. In 2017, a backdoored version of CCleaner was signed with Avast's legitimate code-signing certificate and distributed through official download servers, reaching approximately 2.27 million users before discovery.¹ In 2020, the SolarWinds Orion software update pipeline was compromised and inserted malicious code into packages signed by SolarWinds with a valid certificate.² On PyPI, researchers counted 40 typosquatting attacks: packages with names similar to trusted ones that contained malware and were removed from the registry.³

What hash verification does and does not protect against

Hash verification confirms one specific property: the file on your disk is byte-for-byte identical to the file the publisher measured when generating the checksum. If the publisher's own infrastructure was compromised before the checksum was generated, the published hash matches the compromised binary and verification passes. Combining hash verification with GPG signature verification adds a meaningful second layer. When the signature validates against the developer's own public key, you also have assurance that the key holder approved the specific binary you downloaded.

The practical takeaway is that hash and signature answer different questions. The hash proves the file is unchanged since the publisher measured it; the signature proves the publisher, identified by their key, is the one who measured it. Use both when the publisher offers a signed checksum, and treat a matching hash alone as sufficient only when the distribution channel is already trustworthy.

Where to find checksums for common software downloads

Major software publishers include checksums on their download pages, typically adjacent to or below the primary download link. Mozilla Firefox lists SHA-512 checksums for every release at ftp.mozilla.org/pub/firefox/releases/, in a file named SHA512SUMS alongside each version's installer files.⁴ For the Apache Software Foundation, every project release includes SHA-512 checksums adjacent to the download, accompanied by an OpenPGP signature and a KEYS file listing the signing keys.⁵

GitHub Releases pages frequently include checksum files uploaded alongside the release binaries. Look in the list of release assets below the download links for any file whose name contains "checksum," "hash," "sha256," or "sha512"; most projects that publish checksums follow one of these naming conventions. For projects that do not upload a checksum file to GitHub Releases, check the project's official documentation or security page for the canonical checksum location.

Checksum publication for security and cryptographic tools

Security tools treat hash verification as a prerequisite rather than a recommendation. For GnuPG releases at gnupg.org, each distribution includes SHA-1 checksums alongside detached OpenPGP signatures; verify both the hash and the signature for the strongest assurance.⁶ VeraCrypt publishes SHA256 and SHA512 checksums for each installer on its download page at veracrypt.fr/en/Downloads.html alongside a PGP signature file, and catching a tampered binary before it runs takes just a pasted hash and a dropped file.⁷ For any security tool where an attacker would benefit from your running a backdoored version, treating hash-and-signature verification as mandatory is the appropriate baseline.

The same discipline applies to operating-system and driver updates from vendor portals, where a compromised installer can gain kernel-level access on every machine it touches. A 30-second hash check before running a downloaded .exe or .msi is a cheap guard against exactly that class of compromise. CapyToolkit computes SHA-256, SHA-512, SHA-1, and MD5 for any file entirely in your browser, so you can confirm the value matches the publisher's posted checksum without uploading anything.

Building a consistent verification workflow and choosing the right algorithm

Establishing a verification habit means performing the same three steps for every download: retrieve the file, retrieve the publisher's checksum, then compare the values before opening or running the file. Keeping these steps in the same order every time prevents the common mistake of running a file before verifying it. For frequently updated software, bookmark the checksum file URL so you can retrieve it immediately on every future update without searching.

SHA-256 is the current standard and the algorithm to prioritize when a publisher offers multiple options. Both SHA-256 and SHA-512 are considered equally secure for download verification; SHA-512 provides a larger 128-character digest but offers no meaningful security advantage for this use case.⁸ MD5 produces a 32-character digest and has known collision weaknesses demonstrated in 2004, making it suitable for detecting accidental corruption but significantly weaker against deliberate tampering.⁹ For software verification, use SHA-256 or SHA-512 whenever available and fall back to MD5 or SHA-1 only when no stronger hash accompanies the download.

Verifying downloads received through email or file transfer

Software packages received through email, messaging platforms, or shared drives add a verification dimension that URL-based downloads do not. Instead of relying on the sender's word that the file is authentic, obtain the expected SHA-256 hash from the software publisher's official website independently, then verify the received file against that hash. This check distinguishes an authentic binary the sender forwarded legitimately from a binary that was substituted at some point in the transfer chain.

When to use this

Use this before running any installer, executable, or archive downloaded from the internet, especially if the download was from a mirror, a torrent, or a third-party distribution site.

Examples

File: app-installer-v2.1.0-windows-x64.exe
Published SHA-256: a1b2c3d4e5f6...

Computed SHA-256: a1b2c3d4e5f6...
Result: MATCH

Verify ISO File Integrity After Downloading

Linux distributions, Windows ISOs, and bootable tools all publish SHA-256 checksums alongside their download links. Comparing the checksum of your downloaded file against the published value is the only way to confirm the file is complete, unmodified, and not tampered with in transit.

How SHA-256 checksums detect corruption and tampering

When you hash a file with SHA-256, the algorithm produces a 64-character hexadecimal fingerprint regardless of the file's size. Your browser processes the data in 512-bit blocks and outputs a fixed 256-bit digest at the end.¹ A 4 GB ISO and a 100-byte text file each produce a 64-character hex string, which makes SHA-256 practical as a verification target even for multi-gigabyte operating system images.

Two files that differ by even a single bit produce completely different SHA-256 hashes. This property, called the avalanche effect, means a partial download that dropped its final megabyte produces a hash that looks nothing like the expected value.¹ Corruption becomes immediately apparent. SHA-256 catches both accidental file corruption and deliberate modification with equal reliability, which is why every major OS distribution publishes these checksums alongside their downloads.

Hash algorithm generations and when to use each

You may encounter MD5 or SHA-1 on older distribution pages for some Linux releases. Both have known weaknesses: MD5 collision attacks were demonstrated in 2004,² and Google demonstrated a practical SHA-1 collision in 2017 in the SHAttered research.³ A collision means two different files produce the same hash value. For well-resourced attackers, this property reduces an algorithm's assurance against deliberate file substitution. When you verify an ISO, use SHA-256 whenever the publisher provides it. Fall back to MD5 or SHA-1 only when no stronger option appears on the publisher's page.

Finding the published checksum for major operating system ISOs

Ubuntu publishes SHA-256 checksums as a file named SHA256SUMS at releases.ubuntu.com, in the same directory path as the ISO download.⁴ Each line pairs a 64-character hash with a filename. Locate the line matching your downloaded ISO and copy the 64-character hex string that precedes it. Alongside the main checksum file, a SHA256SUMS.gpg file in the same directory lets you verify the checksum file itself against Ubuntu's release signing key, adding a layer of assurance beyond the hash alone.

Fedora provides a CHECKSUM file alongside each image on official download mirrors.⁵ Lines follow the format SHA256 (Fedora-Workstation-Live-x86_64-41-1.4.iso) = <hash> rather than the plain sha256sum format Ubuntu uses. The 64-character value appears after the equals sign. At cdimage.debian.org, Debian lists SHA256SUMS files in the same directory path as its ISO files, following the same plain format.⁶

Tails and Kali Linux checksum locations

Tails publishes SHA-256 hashes at tails.boum.org/install and recommends the Tails Verification browser extension, which automates the comparison step if you prefer a guided workflow, but you can verify a Tails ISO directly and skip the extension entirely.⁷ For Kali Linux, the official downloads page at kali.org/get-kali lists per-image SHA-256 checksums, accessible by expanding the checksum section beside each image variant.⁸ Both distributions treat hash verification as a documented and required step in their official installation instructions rather than an optional confirmation.

Command-line verification and diagnosing hash mismatches

On Linux, running sha256sum ubuntu-24.04-desktop-amd64.iso in a terminal prints the computed hash followed by the filename. The macOS equivalent is shasum -a 256 ubuntu-24.04-desktop-amd64.iso, which produces output in the same format. Both commands process your file in streaming fashion without loading it entirely into memory, making them practical for multi-gigabyte ISOs on any hardware.

For automated comparison on Linux, paste the expected hash from the publisher and run echo "EXPECTEDHASH filename.iso" | sha256sum -c in the directory containing your downloaded file. If the computed hash matches, the command prints "filename.iso: OK". A mismatch produces a "FAILED" message and exits with a non-zero status code. On Windows 10 and later, you can run Get-FileHash -Path .\yourfile.iso -Algorithm SHA256 in PowerShell to obtain the same digest natively.

When a mismatch might indicate a mirror problem

A hash mismatch after downloading an ISO almost always results from an incomplete or interrupted transfer rather than deliberate tampering. If the mismatch persists across multiple fresh downloads from the same mirror, try a different official mirror or network connection before concluding the file itself is the issue. Mirror servers occasionally serve outdated cached versions that match the expected file size but differ in content.

Pasting the wrong expected hash is the most common source of false mismatches during manual verification. Publisher download pages frequently list checksums for multiple editions on a single page. Copying the hash from the wrong row is an easy mistake. Before you download again, confirm the expected hash corresponds exactly to the filename and edition you downloaded.

When to use this

Use this immediately after downloading any bootable ISO: Ubuntu, Debian, Fedora, Tails, Windows, or any operating system image. Always verify before writing to a drive.

Examples

File: ubuntu-24.04-desktop-amd64.iso
Published SHA-256: 8762f7e74e4d64d72fceb5f70682e6b069932deedb4949c6975d0f0fe0a91be3

Computed SHA-256: 8762f7e74e4d64d72fceb5f70682e6b069932deedb4949c6975d0f0fe0a91be3
Result: MATCH. Download verified.

Verify npm Package or Archive Integrity Before Installing

The npm registry stores a SHA-512 integrity hash for every published package version. When you download a tarball manually or receive one from a colleague, comparing its hash against the registry entry confirms you have the authentic, unmodified package rather than a tampered version.

How npm's integrity field and SRI format protect package consumers

The npm registry stores a SHA-512 hash for every published package version in a field called integrity. Formatted as a Subresource Integrity (SRI) string, this value begins with "sha512-" followed by a base64-encoded representation of the hash, for example: sha512-v2kDEe57lecTulaDIuNTPy3Ry4gIPhqjtVGJqZkGLx5KrSvHOkqdmdQEF9igwMgTEDT9EPYFNnb9FBWP3FJw==.¹ When npm installs a package, it downloads the tarball, computes its own SHA-512 hash, and compares the result against the registry's stored integrity value; a mismatch causes the installation to fail with an integrity check error.²

Package-lock.json records the integrity value for every installed dependency at the version pinned during the last npm install.³ Running npm ci instead of npm install enforces that every installed package matches the version and integrity value recorded in package-lock.json, rejecting any package that produces a different hash.⁴ On build servers and in CI/CD pipelines, npm ci provides stronger integrity guarantees than npm install because it cannot silently update packages to new versions or accept modified tarballs.

Finding and converting the expected hash for comparison

Running npm view <package>@<version> dist.integrity in a terminal returns the SHA-512 SRI value for any published version, with no local install required.⁵ For packages already in your project, open package-lock.json and search for the package name; the "integrity" field contains the sha512-prefixed SRI value from your last install. The SRI format differs from the raw hexadecimal that most hash tools output. To convert between formats on Linux or macOS, run openssl dgst -sha512 -binary <file> | openssl base64 -A to produce base64 without the SRI prefix, then prepend "sha512-" before comparing against the npm integrity value.⁶

The base64 conversion matters because the tool on this page outputs raw hex by default. A hex string never matches an SRI string directly, so the conversion step is what makes a manual terminal comparison possible. If you skip it and compare hex against the registry's base64 value, every package will appear to fail even when the bytes are identical. Matching an npm tarball to the registry's integrity field skips the hex-to-base64 conversion entirely: drop the file into the tool and paste the integrity value directly.

Verifying npm tarballs in CI/CD pipelines and air-gapped environments

In CI/CD pipelines that cache node_modules or the npm cache directory between runs, a verification step after cache restoration confirms the cached files were not modified between builds. Running npm ci after restoring the cache uses package-lock.json's recorded integrity values as the reference and rejects any cached package that does not match. For pipelines where this automatic check is not sufficient, disable the node_modules cache and use npm ci to install directly from the registry on every run.

Air-gapped environments require npm packages to be bundled and transferred offline. The safest process runs in two stages: in a connected environment, download each tarball and verify its hash against the registry's dist.integrity value using npm view; then transfer the verified files to the air-gapped environment. After transfer, recompute each tarball's hash and compare against the pre-transfer reference to confirm no file was altered during the transfer process.

Auditing offline install bundles with hash verification

Organizations that maintain an approved package bundle for internal distribution benefit from per-tarball hash verification when assembling or auditing the bundle. Compare each tarball's SHA-512 hash against the corresponding npm view <package>@<version> dist.integrity value to confirm every file was sourced directly from the public registry without modification. Any tarball that does not match its registry hash was either corrupted after download, sourced from a non-registry location, or locally modified; each of these scenarios warrants investigation before including the bundle in a production deployment.

Diagnosing npm integrity check failures

An npm integrity error during npm install or npm ci reports the package name, the expected integrity value from package-lock.json, and the computed value from the downloaded tarball. When the computed value does not match the expected value in package-lock.json, the tarball on disk or in the npm cache is corrupted or replaced. If the expected value in package-lock.json does not match the registry's current dist.integrity for the same package version, the package-lock.json file was generated against a different registry state than the one currently returned.

Registry integrity values do not change after a package version is published under normal conditions.⁷ A mismatch between package-lock.json's recorded integrity and the registry's current value for the same version therefore warrants investigation: an integrity value change on an already-published version signals either a registry incident, an undocumented re-publish, or package-lock.json generated against a non-public registry. Before proceeding with installation, contact the package maintainer and check the project's security advisories.

Clearing the npm cache after an integrity failure

After an integrity check failure, clearing the npm cache before retrying prevents a corrupted cached tarball from producing repeated failures on subsequent runs. Running npm cache clean -f followed by a fresh npm install fetches new copies of all packages directly from the registry. If the failure recurs after a clean cache, the issue lies in the registry or package-lock.json rather than the local cache, and further investigation of the package's published state and your package-lock.json is necessary.

When to use this

Use this when installing packages from a private registry, verifying a tarball received by file transfer, confirming a package cached in a CI artifact store, or auditing an air-gapped install bundle.

Examples

File: lodash-4.17.21.tgz
Registry SHA-512 (base64): sha512-v2kDEe57lecTulaDIuNTPy3Ry4gIPhqjtVGJqZkGLx5KrSvHOkqdmdQEF9igwMgTEDT9EPYFNnb9FBWP3FJw==

Computed SHA-512: [matches registry value]
Result: MATCH