When you install a Python package from PyPI, you often download a wheel that somebody else has already built.
You can read the project's source code on GitHub. You can check that the account publishing a release uses Trusted Publishing. PyPI can also provide an attestation linking a distributed file to an identity and a publication workflow.2
A different question remains: does that wheel actually correspond to the source code you inspected?
A paper published in July 2026 measures that gap at scale on PyPI.1 Brett Cannon, a Python core developer, brought it back into discussion on 15 August with a practical question: what is still missing before reproducible builds become an ordinary property of Python packages?4
The answer starts by separating three kinds of proof that are easy to collapse into one.
Provenance does not mean verified contents
PyPI's official documentation is explicit about the boundary of its current attestations: they can tell you where an artifact came from and which publisher produced it, but not whether you should trust the package's contents.2
That is already valuable.
If a new release that normally comes from a GitHub Actions workflow suddenly appears under a different publishing identity, the provenance change can become visible. An attestation can also help detect modification of an artifact after it was built, while it is stored or distributed.2
But that mechanism does not automatically answer what happened before the build.
A repository can contain clean source code while a compromised build pipeline produces something else. Conversely, two honest builds of the same source can differ because of a timestamp, file ordering, an absolute path or a tool version.
A reproducible build tries to close that second gap: an independent party rebuilds the artifact from the same sources and compares the result.3
Ideally, both files are identical byte for byte.
In Python packaging, that is where the trouble begins.
Across 12,180 releases, perfect identity is still uncommon
The “No Snake Oil” study analyses 12,180 popular PyPI releases and uses two independent rebuilding systems: Oracle's macaron and Google's oss-rebuild.1
The harshest result is the rate of exact byte-for-byte equality.
In the macaron sample, 15.4% of rebuilds are identical to the published wheel. For oss-rebuild, the reported figure is 19.1%.1
That does not mean 80% of packages are compromised.
It means a very strict test, “same bytes or failure,” still mixes malicious differences with ordinary build noise.
A wheel is a ZIP archive. Internal ordering, metadata, timestamps or generated build details can change without changing the code that will run. On the other hand, blindly ignoring every difference would make the verification useless.
The authors therefore propose daleq4py, a tool that compares two Python distributions while normalising selected non-semantic differences and preserving information required for provenance.1
With that more structured comparison, the share of rebuilds considered equivalent rises sharply: 60.2% for the macaron set and 78.9% for oss-rebuild when the corresponding sources are themselves considered equivalent.1
That is much better.
It is still not 100%.
Reproducibility is not just a yes-or-no switch
The paper is useful because it shows that build verification has several levels.
The simplest asks whether two archives are exactly identical. It is easy to understand, easy to automate and hard to game. It is also fragile in the face of metadata that does not affect the program.
The next level asks whether differences are explainable and execution-preserving. That is more useful, but it requires normalisation rules and evidence that those rules will not hide the important difference on the exact day somebody needs them.1
The Reproducible Builds project has long emphasised the same principle: reproducibility is not about trusting one particular build server. It is about making independent verification of the source-to-binary path possible.3
That is fundamentally different from a signature.
A signature says: “this identity says it produced this file.”
An independent rebuild tries to say: “from these sources and instructions, I can produce the same file too, or an artifact whose differences have been explained.”
The two proofs complement each other. They do not replace each other.
PyPI already has part of the puzzle
It would be easy to read the study as an argument against PyPI attestations. That would miss the point.
PyPI's own security model explicitly recognises its boundary. The current attestation mostly protects the publication chain and publisher identity. The documentation itself points toward reproducible builds for guarantees about what happened during construction.2
In other words, PyPI is not pretending to have solved the problem the paper measures.
What is missing is a more ordinary connection between the layers: known source, known workflow, attested artifact, sufficiently deterministic build environment, then independent reconstruction when the risk level justifies it.
Projects such as oss-rebuild are already working on that last part at scale.5
The paper also shows a Python-specific obstacle: rebuilding is not enough when the packaging chain generates irrelevant differences every time.
Before detecting malicious changes, the ecosystem has to reduce normal noise.
Proof becomes a property of the manufacturing process
To a developer, a wheel looks like a software file.
To the security chain, it looks more like a manufactured part.
The source repository is the plan. The build system is the workshop. The wheel is the object that leaves the machine. An attestation documents who started production and in what context. An independent rebuild tries to manufacture the part again from the same plan and see whether the result matches.
The analogy has limits: reproducing a binary is not physically the same as machining two parts. But it makes the missing proof visible.
Reading the plan does not prove what is inside the package you received.
PyPI is getting better at documenting the package's journey. The 2026 study shows that making reconstruction of the contents an ordinary check rather than a research operation still requires substantial work.
That is not a reason to trust attestations less.
It is a reason to ask them for exactly the proof they know how to provide, then build the next proof instead of using the same word, “trust,” for every stage of the chain.