Not with PGP. In 2023 PyPI stopped serving new PGP signatures and silently ignores any that are uploaded, after an audit found most could not be meaningfully verified. To check a package today, rely on hashes you recorded and, where a project publishes them, attestations tied to its build.
What PyPI announced
The PyPI blog post "Removing PGP from PyPI" explains the change. Uploads that include signatures still succeed, but the signatures are silently ignored. Existing signatures should continue to be available for now, but may be removed in the future, and the related API fields such as has_sig were hardcoded to always be false.
The reason was practical. The post reports that in the previous three years about 50,000 signatures were uploaded by 1,069 unique keys. About 30 percent of those keys were not discoverable on major public keyservers. Of the rest, nearly half could not be meaningfully verified at the time of the audit. Only 36 percent of the keys could be meaningfully verified, and the post calculates that this would cover at most 0.3 percent of files even in the best case.
What this means for a verification plan
If you were hoping to run a signature check on every install, there is nothing consistent to check. The ecosystem never had a trusted key distribution story for PyPI projects, which is the underlying weakness the post points to.
So the practical options are different ones:
| Option | What it proves | Limits |
|---|---|---|
| Local hashes in requirements | The file matches what you reviewed | Says nothing about whether the release is safe |
| Trusted publishing | The release was uploaded from a named build workflow | Depends on the project using it |
| Attestations (PEP 740) | A signed statement tied to that publishing identity | Only exists where a project publishes them |
| Pinning plus review | You chose a specific version deliberately | Needs human time |
For the attestation story see what PEP 740 attestations prove and PyPI trusted publisher setup for GitHub Actions. For the hash approach see how pip hash checking works.
If you publish packages
Do not tell users to verify a PGP signature. Instead:
- Publish through trusted publishing so the upload is tied to a workflow.
- Keep release notes and tags consistent, so reviewers can compare.
- State in your README how users can pin and hash your releases.
If you consume packages
- Pin exact versions and record hashes for production installs.
- Review what changes in a new version before you accept it.
- Watch for new maintainers or sudden changes in a dependency's behaviour.
- Keep an inventory, so when an advisory lands you can answer "do we use this" quickly.
Why a lost signature feature is not a crisis
A signature that almost nobody can verify gives a false sense of safety. The PyPI post treats removal as the honest outcome. The controls that replaced it are less glamorous, but you can check them yourself and automate them.
Safeguard's SBOM and dependency scanning keep that inventory current for Python projects, and its policies can block a release path when a dependency fails your rules. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do old PGP signatures on PyPI still download?
The PyPI post says existing signatures should continue to be available for now, but may be removed in future. No new ones are served.
What replaced signature checks for most teams?
Local hashes, version pinning, and where available, trusted publishing and attestations. None of them replaces reviewing what you install.
Sources
Last reviewed: 19 October 2026.
