You just downloaded a 2.4 gigabyte Fedora ISO
The progress bar hit one hundred percent, but your network dropped for three seconds near the end. You flash the image to a USB drive, reboot, and the Anaconda installer halts with a file system corruption error. Or you complete the installation, only to discover weeks later that a compromised package replaced your core system binaries. Verification is not a paranoid ritual. It is the first line of defense against a broken install or a supply-chain compromise. Run the checks before you write the image to disk.
What is actually happening
A software download involves two separate guarantees. The checksum proves integrity. It answers whether the bits on your disk match the bits on the server. A single flipped bit during transmission will change the hash entirely. The GPG signature proves authenticity. It answers whether the Fedora release engineering team actually built this image. A checksum alone cannot stop a malicious actor from swapping the ISO on a compromised mirror. The signature ties the file to a specific cryptographic key that only Fedora maintainers control. Think of the checksum as a receipt total and the signature as the manager official stamp. You need both to trust the software.
Fedora publishes three files for every release. The .iso file contains the operating system. The .sha256 file contains the expected hash. The .sig file contains the detached GPG signature. Detached signatures are standard in Linux distributions. They keep the cryptographic proof separate from the payload so you can verify the file without modifying it. You must download all three to the same directory before you begin.
The math behind GPG verification relies on asymmetric cryptography. Fedora signs the ISO with a private key. Your system verifies it using the corresponding public key. The public key is safe to distribute. The private key stays in Fedora infrastructure. When you run the verification command, GPG decrypts the signature with the public key and compares the resulting hash to the hash of your ISO. If they match, the file is authentic and unmodified.
The fix
Open your terminal and navigate to the folder containing your downloads. You will run two distinct verification steps. The first checks the hash. The second validates the cryptographic signature.
Here is how to verify the SHA-256 checksum against the official hash file.
cd ~/Downloads
# Change to the directory where the ISO and hash file live
sha256sum -c Fedora-Workstation-Live-43-1.5.x86_64.iso.sha256
# -c tells sha256sum to read the expected hash from the file and compare it
The command reads the .sha256 file, computes the hash of the ISO, and prints OK if they match. If the output says FAILED, your download is incomplete or corrupted. Redownload the ISO and the checksum file. Do not proceed to the signature check until the hash passes.
Here is how to import the official Fedora GPG key into your local keyring.
gpg --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$(rpm -E %fedora)-primary
# rpm -E %fedora expands to your current release number automatically
# This pulls the key that ships with Fedora into your personal GPG keyring
Fedora ships the release key in /etc/pki/rpm-gpg/ for package manager use. GPG does not read that directory by default. Importing it into your ~/.gnupg/ keyring lets the command-line tool verify detached signatures. If you are on a fresh system and the key file is missing, download it directly from the Fedora infrastructure website instead. The rpm -E %fedora macro is a standard Fedora convention that keeps your commands release-agnostic.
Here is how to verify the detached signature against the ISO.
gpg --verify Fedora-Workstation-Live-43-1.5.x86_64.iso.sig Fedora-Workstation-Live-43-1.5.x86_64.iso
# The first argument is the signature file. The second is the actual ISO.
# Order matters. GPG will fail silently if you swap them.
GPG will output a block of text showing the key ID, the algorithm, and the verification result. Look for the line that says Good signature. If you see BAD signature, the file was altered after signing. If you see NO_PUBKEY, your keyring is missing the correct release key.
Verify it worked
A successful run produces two distinct confirmations. The checksum command prints Fedora-Workstation-Live-43-1.5.x86_64.iso: OK. The GPG command prints Good signature from "Fedora (43) <fedora@fedoraproject.org>". Both must appear. If GPG prints a warning about the key not being fully trusted, ignore it. GPG web of trust model is designed for personal email encryption, not distribution verification. As long as the key ID matches the official Fedora release key and the signature is good, the image is authentic.
Run gpg --list-keys fedora@fedoraproject.org to confirm the key fingerprint matches the one published on the Fedora security page. Cross-referencing fingerprints prevents man-in-the-middle attacks on the key server itself. Fedora publishes the official fingerprints in their release notes. Compare the 40-character hex string manually. Trust the package manager for daily updates. Verify the ISO before you write it to disk.
Common pitfalls and what the error looks like
Verification fails for predictable reasons. The most common mistake is running the commands from the wrong directory. sha256sum -c looks for the ISO relative to the hash file. If you run it from /tmp, it cannot find the image and prints a missing file error. Always cd into the download folder first.
Another frequent issue is filename mismatch. Fedora sometimes updates the release number or build suffix. If your ISO is version 43-1.6 but your hash file says 43-1.5, the checksum will fail. The error output will show OPEN FAILED or FAILED open or read. Download the matching .sha256 and .sig files from the exact same release page.
GPG will occasionally print a warning about trust levels. Here is what that output looks like in the terminal.
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9085 0DE2 5F42 DD64 9F1C 3F3D 6310 9C4B 39A1 0182
This is normal. It means your local keyring has not been manually signed by someone you trust. The cryptographic math still validates. The warning is a social trust prompt, not a cryptographic failure. If you are automating this in a script, add the --batch flag to suppress interactive prompts.
If you see gpg: can't connect to the agent: No such file or directory, your GPG agent is not running. Run gpgconf --kill gpg-agent followed by gpg --verify again. The agent will restart automatically on the next call. SELinux does not block GPG operations on user home directories, so you do not need to adjust contexts for this workflow.
Check the exact error text before guessing. A missing key requires an import. A bad hash requires a redownload. A swapped argument order requires a rerun. Run journalctl first. Read the actual error before guessing.
When to use this vs alternatives
Use sha256sum -c when you only need to confirm the download survived network transmission intact. Use gpg --verify when you require cryptographic proof that Fedora engineering produced the image. Use both commands together when you are installing on a machine that handles sensitive data or serves as your primary workstation. Skip verification entirely only when you are testing in an air-gapped virtual machine with no persistent storage. Trust the checksum for speed. Trust the signature for security. Verify both before you boot.