PyPI: accepting a release file with evidence of its origin
The new Security tab makes file origins easier to inspect on PyPI. Acceptance needs to follow the distribution that will be delivered and the limits of the available evidence.
Читать на португальскомBy Pentesty
What changed, and what still needs review
In its November 6, 2026 announcement, PyPI described the completed redesign of project pages. The Security tab brings together signals about file origins. Attestations have existed since 2024: the update makes them easier to find and warnings easier to interpret, without turning the repository into a certifier of code safety.
For businesses, the useful outcome is a documented decision about the distribution that will be delivered. An approved version record can coexist with files intended for different platforms. The team needs to know which file reached the production artifact and which evidence supported its acceptance.
Start with the file that will be consumed
Choose a package used by a service you own. Record the project, version, exact filename, target platform and approval owner. In Release Files, locate that distribution and inspect its provenance status. Retain the observation time and the consulted reference, without installing a file merely to examine it.
Then compare the other files in the same release. Full provenance means every file has attestations; incomplete provenance requires examining those without them. An absent attestation does not establish malware. Record the gap and the decision rationale, rather than assigning a security conclusion that the evidence cannot support.
Separate integrity, identity and safety
The integrity documentation explains how to compare a file’s SHA-256 with PyPI’s record. This comparison binds the acquired bytes to the published file. It does not establish that the code is trustworthy or replace assessment of the channel used to obtain the checksum.
Define which identities and fields your policy actually requires. If a record does not provide the commit required by the process, treat the gap as a pending decision. Document who may accept an exception and its deadline. Assess separation between production and approval as well: the process generating a file should not independently authorize every new origin. Give the approver a comparison against the previously accepted value and retain the inputs used to reach the decision.
Investigate warnings with your own comparison
According to the provenance documentation, files may have inconsistent origins or change repository or workflow. These situations can also have legitimate explanations. Compare the observed identity with the approved configuration and public project notes; document an expected migration before accepting the change.
Change and loss warnings compare against releases from the preceding 14 days. Preserve your own history of accepted artifacts as well. An absent UI warning does not establish historical continuity. Visiting the tab also does not implement automatic attestation verification in an installer or delivery pipeline.
Define a test without running unknown code
In an authorized environment, prepare synthetic records for two distributions of the same internal package. Define an accepted publishing identity and a second origin that must require review. Check whether the rule evaluates each file and records the expected decision, including a deliberate exception for missing metadata. Do not use campaign samples.
The report should connect the file, checksum, consulted attestation, verification result and release owner. If the company adopts automated cryptographic verification, validate its identity policy and outcomes against the official attestation-consumption instructions. A permissive rule accepting any issuer does not satisfy a policy about the expected origin.
Carry the evidence into the delivered environment
Connect the accepted distribution to the build and the service that received it. Our analysis of PolinRider and dependency execution complements that trail: acquisition, execution and access provide different evidence. After pipeline changes, repeat both allowed and blocked cases and confirm that legitimate operation remains possible.
Include an additional negative control: retain a fictional distribution’s filename but change its bytes in a laboratory copy. The policy should identify the mismatch before allowing consumption, even if an earlier record has that filename. Retain the expected checksum, observed checksum, rejection stage and valid-case outcome. This evidence lets the owner assess whether a cache, mirror or packaging-stage change preserved the intended control. It does not replace code review or establish the safety of an actual dependency. Keep the exercise separate from production credentials and from real third-party release files.
Frequently asked questions
Does full provenance guarantee a safe package?
No. Define file acceptance criteria and separately assess the code, environment and approver’s authority.
Does an absent attestation mean malware?
No. Define who reviews the gap and which evidence authorizes an exception for the required file.
Does the Security tab make an installer block releases automatically?
No. The interface presents information. The business needs to define and verify a consumption policy and its enforcement controls.
Why retain the exact filename?
A version can contain multiple distributions with different provenance. The record needs to identify the one actually delivered to the service.
Sources and references
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.