📋 Table of Contents
A checksum comparison and a signature check answer different, limited questions. A SHA-256 match is strong evidence that your file has the same bytes as the file represented by the expected value. That comparison is meaningful only when the expected value came through an authenticated publisher channel rather than beside the same untrusted download. A valid signature shows that the signed bytes match the signature and identifies a certificate or public key; you still need to confirm that signer is the one the publisher documents. Neither result is a malware scan or a guarantee that the software is safe.
This guide uses platform tools to collect that evidence and explains where the trust decision still belongs to you. Commands and interfaces can vary by operating-system release, so follow the linked platform documentation when output differs.
1 Start with an authenticated reference
Before calculating anything, obtain the installer and its expected checksum or signing-key fingerprint from channels the publisher controls: for example, its HTTPS download page, signed release notes, or documented release repository. A checksum copied from the same untrusted mirror as the file offers little independent evidence because both could have been replaced together. Save the source URL, filename, version, architecture, and retrieval date with your deployment record.
A hash comparison answers whether two byte sequences match; it does not identify who created those bytes. A signature can bind signed bytes to a certificate or key, but only after the certificate chain or key fingerprint is connected to the expected publisher. Microsoft's Get-FileHash documentation describes hashes as a way to check file contents, while its Authenticode documentation explains the certificate-chain component of publisher identification.
2 Check a SHA-256 hash on Windows
In PowerShell, run Get-FileHash -LiteralPath .\installer.exe -Algorithm SHA256. Microsoft documents the cmdlet and its SHA-256 default in the Get-FileHash reference. Command Prompt also provides certutil -hashfile "C:\path\installer.exe" SHA256; see Microsoft's certutil reference.
Compare the complete hexadecimal result with an expected SHA-256 value obtained from the authenticated publisher channel. Ignore letter case and formatting spaces, but not missing or changed digits. A match supports the conclusion that the files represented by the two values have the same contents. It does not establish where the expected value came from or whether the matched software is benign.
3 Check a SHA-256 hash on macOS and Linux
On macOS, shasum -a 256 /path/to/installer.dmg calculates a SHA-256 value. On Linux systems with GNU Coreutils, use sha256sum /path/to/installer; the authoritative GNU SHA-2 utilities documentation also describes checksum-file verification.
If the publisher supplies a correctly formatted checksum file, sha256sum -c checksums.txt can compare listed files automatically. Authenticate that checksum file just as carefully as a checksum shown on a web page. An OK result means the local file matches the listed digest; a mismatch or unexpected filename means you should stop and investigate rather than execute the file.
4 Verify the digital signature on Windows
For a signed Windows file, open Properties → Digital Signatures, select a signature, and inspect Details. Compare the signer name with the legal entity the publisher documents, and review the reported status and certificate chain. PowerShell can expose the same evidence with Get-AuthenticodeSignature -LiteralPath .\installer.exe; Microsoft documents the fields and platform limitation in the Get-AuthenticodeSignature reference.
A valid Authenticode result indicates that Windows can validate the signature under its current trust configuration and that the signed content has not changed since signing. It does not say that the code is harmless, that the certificate has never been misused, or that an unsigned file is necessarily malicious. If a publisher says its release is signed but your copy has no matching valid signature, stop and obtain clarification from the publisher.
5 Inspect macOS and OpenPGP signatures
On macOS, spctl -a -vv /Applications/App.app asks Gatekeeper to assess an app, while codesign -dvv /Applications/App.app displays signing information. Apple's Gatekeeper and runtime-protection documentation explains that Gatekeeper considers developer identification, notarization, alteration, and local policy. Compare the displayed developer or Team ID with the publisher's documentation; an accepted assessment is evidence within that trust system, not a safety guarantee.
On Linux and other platforms, some projects publish a detached OpenPGP signature. GnuPG may need to be installed separately. Obtain the project's public key through an authenticated channel, compare its full fingerprint with an independently published official fingerprint, and then run gpg --verify installer.tar.gz.sig installer.tar.gz. A "Good signature" result says the data was signed by the corresponding private key. It does not by itself establish who controls that key. The GNU Privacy Handbook specifically recommends checking a key's fingerprint before relying on it.
6 What to do when a check fails
If a checksum differs from the publisher's authenticated value, or a signature expected by the publisher is missing, invalid, expired without a trustworthy timestamp, revoked, or names the wrong signer, do not execute the file while the discrepancy is unresolved. Check that you selected the correct version and architecture, retrieve a fresh copy from the publisher's documented channel, and compare again. If the result still differs, ask the publisher or your security team rather than overriding the warning.
A passing check should be recorded as one layer of evidence, not a final verdict. Keep endpoint protection current, review the requested privileges and release notes, test important packages in an isolated environment, and preserve the source URL, expected digest, observed signer, and verification time for repeat deployments.
Frequently Asked Questions
What is a SHA-256 checksum?
SHA-256 produces a 256-bit digest from a file's contents. Matching an expected value obtained through an authenticated publisher channel is strong evidence that your file has the same bytes as the file represented by that value. The match does not identify the publisher or show that the software is safe.
How do I check a file hash on Windows?
Run Get-FileHash -LiteralPath .\yourfile.exe -Algorithm SHA256 in PowerShell, or certutil -hashfile yourfile.exe SHA256 in Command Prompt. Compare the complete result with a SHA-256 value obtained from the publisher's authenticated site or signed release material.
What does a digital signature tell me that a hash does not?
A hash comparison shows whether your file matches the bytes represented by an expected digest. A valid signature ties signed bytes to a certificate or public key. You must still authenticate the digest source, certificate identity, or key fingerprint and decide whether the software itself is trustworthy.
Is it bad if an installer is unsigned?
Not necessarily, because signing practices differ by platform and project. Treat an absent signature as missing evidence. If the publisher states that its release is signed, or your deployment policy requires signing, do not proceed until the discrepancy is resolved through the publisher's documented channel.
Conclusion
A useful verification record is a chain, not a green check in isolation: an authenticated publisher source, the exact filename and version, a matching digest where one is published, and a signer identity or key fingerprint that matches the publisher's documentation. Hashes and signatures can expose important inconsistencies, but neither demonstrates that code is safe. Combine them with source validation, endpoint protection, least privilege, and testing appropriate to the package's risk.
When any link in that chain is missing, describe the limitation instead of promoting the result to a guarantee. That makes the record honest enough to support later audits and repeat deployments.