← back to PyPI Provenance Check
pypi-attestations verify?PyPA's own tool already verifies a PEP 740 attestation:
pip install pypi-attestations pypi-attestations verify pypi --repository https://pypi.org
It's the reference implementation, it's accurate, and if all you want is a one-time answer for one artifact you already have, it's the right tool -- this page isn't arguing against it. What it doesn't do is what this tool exists for.
1. It needs one artifact at a time, already resolved. pypi-attestations verify checks a single wheel or sdist you point it at -- a URL or a local path. This tool works from a pasted requirements.txt, PEP 621 pyproject.toml, or even a plain list of names, resolving each package's latest or pinned version and its file itself. Useful when you're evaluating a whole dependency set before installing it, reviewing someone else's requirements file they sent you, or checking a repo you haven't cloned.
2. It's one package at a time, with no report to hand off. If you maintain (or audit) more than one project, there's no built-in way to see "which of these 40 repos still has unmigrated dependencies" without invoking the CLI once per artifact and collecting results by hand. This tool's CLI emits --json for the whole file in one run, so a script can loop over repos and diff the output.
3. No bulk or CI-shaped output. pypi-attestations verify is built to verify one artifact's cryptographic bundle, not to summarize a project's dependency tree. The CLI here has a flag built for exactly that:
node cli.mjs requirements.txt --without-provenance-only --json
which returns just the packages still missing an attestation, as JSON, ready to file into a spreadsheet, a Slack digest, or a migration tracker.
There is no separate provenance database. Both pypi-attestations verify and this tool read from PyPI's PEP 740 integrity API -- attestation_bundles on a release file -- so they will never disagree about whether a given file carries an attestation. The difference is entirely in what you can start from and what you get out, not in what's being measured. pypi-attestations verify additionally checks the attestation's cryptographic validity end-to-end (the Sigstore bundle, the certificate chain, the Trusted Publisher identity match); this tool reports presence/absence and the publisher named in the certificate, but does not itself re-verify the cryptographic signature -- for that, run pypi-attestations verify against the specific file this tool flags.
It verifies the same underlying attestation this tool reports on, and it does the full cryptographic check this tool does not. What it does not do is work from a requirements file or pyproject.toml before you have downloaded anything, produce a report across more than one project, or emit JSON another tool can consume in bulk. Those three gaps are what this tool adds.
No. Both read from PyPI's own PEP 740 integrity API for the exact same release file. There is no separate provenance database for either tool to disagree about.
When you already have a specific artifact (a URL or a downloaded file) and need the full cryptographic verification -- certificate chain, Sigstore bundle, Trusted Publisher identity match -- not just a presence/absence report across a dependency list.