repomatic.deps.provenance module¶
PEP 740 provenance of the PyPI releases a sync bumps to.
A project publishing through PyPI’s trusted publishing uploads every release
from its own workflow, which attaches the provenance on its own. So a release
with no provenance, after one that carried it, was uploaded some other way:
by hand, or with a stolen API token, the shape most PyPI account takeovers
take. sync-uv-lock and sync-tool-versions hold such a bump back and report
it instead of adopting it unread.
The check fails open on a lookup PyPI does not answer: an unknown provenance holds nothing, since a transient error is not evidence. A trusted publisher that changes between two releases is flagged in the report and held neither: a repository transfer or rename changes it legitimately.
The cooldown and the provenance check guard different things. The cooldown waits for a compromise to be noticed and the release pulled. The provenance check catches the upload that bypassed the project’s pipeline, which a quiet compromise can survive a cooldown with.
- class repomatic.deps.provenance.PypiBump(name, package, old, new)[source]¶
Bases:
objectOne version move of a PyPI package, as a sync is about to make it.
- class repomatic.deps.provenance.ProvenanceReview(cells, holds)[source]¶
Bases:
objectThe provenance of a run’s PyPI bumps.
- holds: list[ProvenanceHold]¶
The bumps to withhold, in the order of the bumps reviewed.
- repomatic.deps.provenance.provenance_cell(new, old)[source]¶
Render the “Provenance” cell of a bump to new from old.
- Parameters:
new (
ReleaseProvenance) – Provenance of the release the bump moves to.old (
ReleaseProvenance|None) – Provenance of the release it replaces,Nonefor an added package.
- Return type:
- repomatic.deps.provenance.is_regression(new, old)[source]¶
Whether a bump from old to new lost provenance.
Both lookups must have answered: an unknown side proves nothing.
- Return type: