Download the KEYS file, the release archive, its .asc signature and its .sha512 file from the main Apache distribution directory, import the keys, run a GPG verify, then compare the SHA512 hash. A "Good signature" line plus an empty diff means the archive matches what the release manager published.
Why bother
Most teams install Airflow with pip and never look at the signature. For a platform that holds credentials to your warehouse and your cloud, the extra five minutes is cheap, and it matters most when you mirror releases internally or build images from source tarballs. A signature proves the file matches what a release manager signed. It does not prove the code is free of bugs.
The steps
These follow the Airflow documentation for installing from sources. Replace the version with the one you are installing.
- Get the KEYS file. The docs say to download it "from the main distribution directory and not from the mirrors".
- Import it.
gpg -i KEYS
- Download the source tarball and its .asc file, then verify.
gpg --verify apache-airflow-3.3.2-source.tar.gz.asc apache-airflow-3.3.2-source.tar.gz
- Look for a "Good signature from" line.
- Check the checksum.
shasum -a 512 apache-airflow-3.3.2-source.tar.gz | diff - apache-airflow-3.3.2-source.tar.gz.sha512
No output from diff means the hashes match.
The warning you will see
GPG will probably print that the key is "not certified with a trusted signature". The Airflow docs say you can ignore this, because most release manager keys are self-signed. The warning means you have not personally established trust in the key. What matters is that the signature is good and the key came from the main distribution directory.
PyPI packages too
The same page includes a script that downloads the wheel for a given version, plus its .asc and .sha512 files, from downloads.apache.org, and you verify them with the same GPG and SHA512 steps. This lets you compare what pip would install against what the project published, which is useful when you build an internal mirror.
Where this fits in a pipeline
- Do the verification once, in the job that builds your internal artifact, not on every worker.
- Store the verified archive hash alongside the build so later audits can see it.
- Record the Airflow version and the constraint file you used in your SBOM.
A checksum on its own only guards against corruption if it is fetched from the same place as the file. The signature adds a check that depends on a separate trust path, which is why both steps matter.
What verification does not cover
Verifying the Airflow archive says nothing about the providers you add, or about the packages in your constraint file. Those come from other places and need their own review. Safeguard's SBOM and dependency scanning can inventory those packages and check them against known advisories; the free scan at https://gold.safeguard.sh/scan is a quick way to try it.
Quick check
Can I get the KEYS file from a mirror?
The Airflow docs say to use the main distribution directory, not the mirrors.
Is the "not certified with a trusted signature" warning a failure?
No. The docs say to ignore it because most release manager keys are self-signed. A failed check would say the signature is bad.
Sources
Last reviewed: 19 October 2026.
