What Stands in the Way of Reproducible Builds on PyPI

While preparing the supply-chain security section of his 2026 nomination statement for the Python Packaging Council, Brett Cannon noticed a striking gap: the Python ecosystem still has no defined way to perform reproducible builds. The appeal of the idea, he says, is that it can be implemented in a way that requires no extra work from distribution authors (the people who upload sdist and wheel packages to PyPI).

Why it matters

Reproducible builds let independent third parties confirm that a package's contents match the source code it was built from. This creates a chance to detect tampering with the build process. A side effect is the need to record the software used during the build, which makes it easier to spot tools that are already known to be compromised. The threat is not hypothetical: the SolarWinds attack was made possible precisely by injecting malicious code into the build process.

Cannon warns against the illusion that pure Python packages are safe: they too are produced by some build backend, and if that backend is compromised, malicious code can end up in the finished wheel.

What the specifications lack

First, nowhere is it recorded which source code was actually used. When installing directly from a repository, this information ends up in the direct_url.json file, but the sdists and wheels themselves don't contain it. It would be enough to write it into the metadata.

Second, an accounting of all the build tools. For wheels there is already an SBOM (software bill of materials) mechanism, added through PEP 770, for which Cannon himself served as delegate. Sdists, however, have no comparable mechanism: it's usually just a tarball with a PKG-INFO file, which has nowhere to put additional metadata. That means we'll either have to accept that sdists aren't suitable for reproducible builds, or develop an sdist v2 format.

Reproducing the build itself is helped by the [build-system] table in pyproject.toml: it specifies the entry point into the backend. If backends learn to record the environment they run in, all the necessary information could be gathered into an SBOM today — with no effort from package authors, but at the cost of work for the pip maintainers.

How to surface this on PyPI

So that the benefit reaches even those who don't want to re-check anything themselves, Cannon proposes an institution of trusted verifiers. Enterprises that already do this kind of checking could report successfully reproduced packages to PyPI, and the platform could mark them: “this file was independently reproduced by such-and-such party.” Installers could even prefer verified builds.

At the same time, the author stresses that the approach shouldn't shame anyone. Reproducibility is a nice bonus, not a requirement. It's like being able to claim that a project meets SLSA level one: some people find it pleasing, but the absence of such a mark is no reproach.

Source: Lobsters