Package provenance makes the release path accountable
PyPI attestations connect a package file to its publishing workflow. Use that evidence to check release identity while keeping code review a separate decision.
By 
Paul. Architecture and infrastructure
A package download should be traceable to the release process you intended to trust. PyPI's digital attestations made that relationship inspectable: a file could carry verifiable evidence connecting it to a repository, publishing workflow and commit. The business consequence is a more accountable dependency decision. You can investigate an unexpected release without treating a familiar package name as sufficient evidence of origin.
Looking back from November 2026 at the November 2024 launch, the useful distinction is between release identity and software behaviour. A valid attestation can support the former. Someone still has to decide whether the identified code and the system that produced it deserve permission to run inside the application.
The launch concerned individual package files
PyPI announced support on 14 November 2024. Its announcement described identity-based signatures, a link to upstream source and verification at upload. It also introduced an Integrity API and a per-file web view. Those are concrete assurance mechanisms, rather than a general promise that packages bearing attestations are harmless.
Automatic generation had specific conditions: GitHub Actions, Trusted Publishing and the PyPA publishing action. Other automatic publishing environments were planned. Reading today's documentation backwards would obscure that initial boundary. The announcement also followed earlier implementation work; 14 November is the announcement date, not a claim that no attestation existed before it.
Simon Willison's contemporary publishing account supplies a useful example. He described an alpha release of his llm package whose file displayed provenance, with a transparency entry exposing the workflow and Git hash. This is his observed publication, not an AL+ test. It shows the sort of evidence a consumer could inspect without proving that every build step had been independently audited.
Decide which identity you expected
Verification has two questions. Does the evidence validate? Does it identify the publisher and release path you meant to accept? The first question concerns the mechanism. The second concerns your dependency policy. An authentic statement associated with an unexpected repository should trigger investigation, even when its signature is valid.
Consider an illustrative internal reporting application that depends on a Python spreadsheet library. Its owner might record the upstream repository and release workflow when approving the dependency. On the next update, the team compares the new artifact's identity against that expectation. A change may be legitimate, such as a repository transfer. The policy should require someone to understand and approve that change before updating the baseline.
This does not require a promise that repository names never change. It requires an accountable decision when the thing being trusted changes. Otherwise a verification badge can become an attractive substitute for the expectation that makes verification meaningful.
The same reasoning applies to files within a release. A wheel and a source archive are different artifacts. Evidence about one should not silently stand in for evidence about the other. Record the file actually selected by the installation process, because that is the object whose identity matters to the deployed application.
A truthful build can contain harmful code
Suppose an authorized maintainer accepts a malicious source change. A correctly functioning release process can publish it with a valid identity. The provenance relationship remains truthful while the dependency becomes dangerous. This is a reasoning example, not a reported PyPI incident or a claim that attestations failed cryptographically.
A compromised workflow presents a related problem. Evidence identifying that workflow helps locate responsibility, but the name of the workflow does not establish that its permissions and inputs were safe. Reviewing release automation remains part of approving the dependency. Provenance narrows uncertainty about origin; it cannot settle every question about the build environment.
This is why code review, dependency selection and release identity should produce separate decisions. Record what changed in the dependency and why it is needed. Review the available identity evidence. Keep any unresolved origin question visible instead of hiding it under a successful installation. None of these steps requires claiming that a human review can guarantee safety either.
The operational benefit is the ability to distinguish questions during an incident. An unexpected file, an unexpected publisher and harmful code from an expected publisher call for different investigations. Conflating them under one word, “trusted”, slows the response and encourages overly broad assurances.
Missing evidence needs a policy of its own
The strongest objection to cautious language is practical: an incomplete security improvement can still prevent useful classes of mistakes. That is correct. Requiring attestations where they are available can improve the release record without pretending they prove code correctness. Their limitations are a reason to define the assurance accurately, rather than postpone adoption indefinitely.
The reverse mistake is to treat absence as proof of malice. At launch, automation support was uneven. A project publishing through another environment could have a responsible release process without the same visible evidence. Your policy can require additional investigation or reject a dependency for a particular risk profile. It should describe that as insufficient evidence for your use, rather than a finding that the maintainer wrote unsafe software.
For a low-risk utility, a recorded exception may be proportionate. For a dependency running with production credentials, the owner may require a stronger release chain. The acceptable exception depends on the application and its exposure, not on an invented universal score.
Before the next dependency update, write down the expected release identity for one important package. Capture the selected file and the available attestation, then name who approves a changed publisher or a missing record. Include that responsibility in custom software development alongside review of the code itself. A useful release policy explains precisely which question each piece of evidence answers.