📋 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.
The commands below are documentation-based examples, not installation-test results. Replace every example filename with your exact file. Run relative-path examples from the folder containing that file; the quotes preserve paths containing spaces.
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 ".\Example Setup.exe" -Algorithm SHA256. Microsoft documents the cmdlet and its SHA-256 default in the Get-FileHash reference. Command Prompt also provides certutil -hashfile "C:\Package Files\Example Setup.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/Example App.dmg" calculates a SHA-256 value. On Linux systems with GNU Coreutils, use sha256sum "/path/to/Example Package.tar.gz"; 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. Inspect the listed filenames and run the check from the directory those relative paths describe. A missing file or unreadable path is a failed check, not a pass. 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 on Windows can inspect signature evidence with Get-AuthenticodeSignature -LiteralPath ".\Example Setup.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 and verify macOS signatures
In macOS Terminal, codesign -dvv "/Applications/Example App.app" displays signing information; it does not verify the signature. Use codesign --verify --deep --verbose=2 "/Applications/Example App.app" to check the app and nested signed code. For an installer PKG, use pkgutil --check-signature "/path/to/Example Installer.pkg". The local man codesign and man pkgutil references describe those distinct operations. These examples inspect existing files; they do not install or launch them.
For an app, spctl -a -vv "/Applications/Example App.app" asks Gatekeeper for a policy assessment. Apple’s Gatekeeper documentation explains developer identification, notarization, alteration checks, and local policy. Compare the developer or Team ID with the publisher’s documentation. Record verification errors separately from an accepted policy assessment; neither is a malware-safety guarantee.
6 Authenticate an OpenPGP key before using it
Some publishers provide a detached OpenPGP signature. Install GnuPG through an approved source if needed. In a terminal with gpg available, work from the folder containing the publisher’s public-key file, detached signature, and package. The names below are placeholders. See the GnuPG command reference and fingerprint-verification guidance.
- 1
Display the downloaded public key: gpg --show-keys --with-fingerprint "publisher-key.asc". Compare the complete fingerprint with an independently obtained official fingerprint before trusting it.
- 2
Only after that match, add this public key to your local keyring: gpg --import "publisher-key.asc". Importing a key does not establish its owner’s identity.
- 3
Verify the detached signature against the exact package: gpg --verify "Example Package.tar.gz.sig" "Example Package.tar.gz". Check both the reported signature result and the expected signer fingerprint.
💡 Tip: A good signature establishes correspondence with a key; authenticate the key’s publisher relationship separately. A missing key, bad signature, or unexpected fingerprint requires investigation.
7 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?
In PowerShell on Windows, run Get-FileHash -LiteralPath ".\Example Setup.exe" -Algorithm SHA256 from the file’s directory, replacing the filename. In Command Prompt, use certutil -hashfile "C:\Package Files\Example Setup.exe" SHA256 with the exact absolute path. Compare the complete result with an authenticated publisher reference.
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.