Summary

  • PyPI explicitly says that removing a user from a project does not remove Trusted Publishers that the user may have registered.
  • A project collaborator role, a configured CI publishing identity, an upload token and a file’s provenance are separate records with different scopes.
  • A defensible offboarding account joins those records without treating the presence or absence of one as proof of every other state.

Offboarding is often narrated as a single action: a person leaves, access is removed, the project is safe. That narration is understandable because an account role is visible and the act of removing it can be decisive. Yet PyPI’s own Trusted Publishing security guidance identifies a boundary that the short version conceals. Removing a user from a PyPI project does not remove the Trusted Publishers that user may have registered. PyPI therefore says that maintainer offboarding should include a review of every Trusted Publisher.

The statement is modest. It does not say that every departed collaborator registered a publisher. It does not say a retained publisher is malicious, that an upload has happened, or that a project is compromised. It says something more useful for governance: two control surfaces exist, and a change in one does not silently rewrite the other. A reviewer who sees only a removed name has evidence of a human role change. They do not yet have evidence about the project’s configured publishing identities.

PyPI’s role descriptions make the distinction concrete. In an organization account, a project Maintainer can upload releases. A project Owner can manage the project and its collaborators. Those are permissions concerning the project’s human administration. Trusted Publishing addresses a different question: whether PyPI should exchange a CI service’s OpenID Connect identity token for a short-lived token that can upload to a particular project. PyPI describes the project as trusting a particular configuration at a CI provider.

The token is deliberately short-lived, but its short lifetime does not merge the configuration register with the collaborator register.

This is why “the account was removed” and “the publishing route was revoked” are not interchangeable sentences. The first describes an account-state event. The second needs an observation of the Trusted Publisher configuration and a decision about each registered identity. A third proposition—“no release was made through that route”—requires an event record. A fourth—“the released file came from an accepted identity”—can be supported, more narrowly, by a file-level publish attestation and its provenance. Each sentence may be true. None is a shortcut for all the others.

PyPI’s attestation documentation helps locate the boundary rather than erase it. A PyPI Publish Attestation can let a verifier establish that a particular distribution was uploaded via a Trusted Publisher and identify the publisher identity used. The Integrity API offers provenance for a named project, version and filename. Those are valuable records of a particular file. They do not reconstruct the administrator’s full offboarding checklist, establish who approved an earlier configuration, or show that a removed person controls a present workflow.

PyPI makes the limit explicit: an attestation can say where a package came from, not whether the identity or the code deserves a verifier’s trust.

The practical problem is record substitution. Teams are good at documenting the closing of a visible account because it has an owner, a timestamp and a user interface. Publisher configurations may sit in a different administrative view, while CI workflow permissions are governed elsewhere again. Under time pressure, a removal ticket can become the only durable evidence.

Months later, someone reviewing a release may find the ticket and assume it answered questions it never asked: which publisher identities were configured, which were examined, whether any were removed, which CI constraints remained, and what release provenance was subsequently observed.

The remedy does not require public disclosure of credentials, repository internals or security-sensitive workflow detail. Daniel Kade recommends an offboarding join record with a bounded purpose. It should name the project and the role event; take an inventory of each Trusted Publisher at a stated time; retain the identity constraints at the appropriate safe level; record the responsible reviewer and whether every publisher was retained, changed or removed; and retain later file-level provenance as a separate observation.

A protected version can hold operational detail while a public or audit-facing version retains the state transition and its authority.

That structure preserves good news as well as bad. A team may remove a collaborator and discover no registered publisher associated with the change. It may intentionally retain a properly reviewed automated route because a different accountable maintainer owns it. It may replace one CI identity with another and later observe clean provenance on a new distribution. None of these outcomes should be guessed from a collaborator list. The objective is not to make every offboarding event suspicious. It is to stop a truthful but narrow access change from acquiring a wider, unsupported meaning.

Sources

  1. PyPI — Trusted Publishers security model
  2. PyPI — Publishing with a Trusted Publisher
  3. PyPI — Roles and entities in an organization account
  4. PyPI Publish Attestation v1
  5. PyPI — Attestation security model
  6. PyPI Integrity API