PYPI PROVENANCE CHECK · TWO READ-ONLY REQUESTS PER PACKAGE

Which of your Python dependencies lack a provenance attestation?

Paste a requirements.txt, a PEP 621 pyproject.toml, or a plain list of package names, and see which ones were published with a PyPI provenance attestation -- PEP 740, PyPI's trusted-publishing signature (OIDC, no long-lived API token to steal) -- and which still rely on a classic upload token.

Your file is parsed in this browser and never uploaded. Checking a package makes two GET requests, from your browser, to the public PyPI API -- pypi.org's package metadata endpoint, then its PEP 740 integrity/provenance endpoint.

1. Paste a requirements.txt, pyproject.toml, or a plain list

Prefer a CLI, or want this in CI?

Same logic, zero dependencies, one file:

node cli.mjs requirements.txt
node cli.mjs requirements.txt --json
node cli.mjs requirements.txt --without-provenance-only
node cli.mjs pyproject.toml                     # unpinned deps: checks the latest published version
echo "pip\nsix==1.17.0" | node cli.mjs -         # freeform list on stdin

Get cli.mjs — Node 18+, nothing to install. Reads only the file you name; the only network calls are the per-package PyPI lookups.

Common questions

Why isn't pypi-attestations verify enough?

pypi-attestations verify checks one already-downloaded artifact at a time, from the command line, with no bulk or CI-friendly report across a requirements file or several repositories. This tool works from a pasted requirements.txt, pyproject.toml, or plain list -- no download or install required -- and the CLI emits JSON for scripting. More: why this exists alongside pypi-attestations.

Does a package without provenance mean it's compromised?

No. PyPI attestations only became available in November 2024, so most published packages predate the feature or their maintainer hasn't migrated yet -- popular, actively maintained packages show up with no provenance attestation too. And the reverse isn't a safety guarantee either: a documented May 2026 worm shipped malicious PyPI and npm packages carrying valid, verifiable attestations, because an attestation proves how a release was built, not that its source code is safe. The absence or presence of provenance is a fact about how a version was published, not a verdict on whether it is safe to install.

Is my requirements.txt uploaded anywhere?

No. The file is parsed entirely in your browser. What does leave your browser is two read-only GET requests per package name/version -- one to pypi.org's package metadata API, one to its PEP 740 integrity/provenance API -- the same public endpoints pip and pypi-attestations already talk to.

What counts as a provenance attestation?

PyPI's integrity API (PEP 740) serves a non-empty attestation_bundles array for a release file published via trusted publishing from a supported CI. This tool reports exactly that: present or absent, and, when present, the publisher's repository and workflow from the attestation's own certificate.

How is this different from a supply-chain security platform like Socket?

Different layers. Socket watches a connected dependency graph and the public registries on an ongoing basis across dozens of risk categories, including Python. This tool answers one narrower, one-time question from a pasted requirements file or the CLI: does this exact release file carry PyPI's own PEP 740 provenance attestation? See this checker vs. Socket.

Been checking packages one at a time on pypi.org? See this checker vs. checking each package on PyPI by hand.