Free tool: runs in your browser
PyPI trusted publishing checklistbefore you set up or change it for a project
TimeBinder adds a layer of protection against AI and human fraud and disputes. Check what you trust, who can change the publish workflow, pending publishers, environments and approvals, old API tokens, and the exact files you can still show.
Nothing you tick is sent anywhere. This page is not a security audit and cannot show that a package or release pipeline is secure.
Check what you trust, the tokens and the copies you can still show
Tick what is true of the project, the workflow and the files you keep. You get a shareable result and clear next steps. Nothing you tick is sent to TimeBinder.
Your choices stay on this page. Nothing you tick is sent anywhere or tied to your name.
Tick everything that is true before you set up or change PyPI trusted publishing
This looks at the current PyPI docs on trusted publishing, which repository and workflow you trust, pending publishers, environments and approvals, old API tokens, and the exact files you can still show. It is not a security audit.
What to do now
What should I check before I set up PyPI trusted publishing? The short answer
Read the current PyPI docs, including the security model. They say to treat your trusted publishers as if they were API tokens. Register only the username, repository and workflow you control and mean to trust, keep the publish workflow small and separate (PyPI suggests naming it release.yml), and give id-token: write at the job level rather than the workflow level. Use a dedicated GitHub environment with required reviewers, since by default anyone who can unconditionally commit can alter the workflow. Decide which old API tokens to revoke once it works, and review a project’s publishers when a maintainer leaves.
This checklist is not a security audit. The docs say trusted publishing does not assert the safety of the code or the trustworthiness of its authors, and does not address whether a package was modified before or after it was built. A TimeBind of a file you already hold can show that exact file existed no later than a recorded time and still matches.
Why this came up in October and November 2026
The PyPI docs on trusted publishing describe it as using OpenID Connect to exchange short-lived identity tokens between a trusted third-party service and PyPI, which removes the need for manually generated API tokens when publishing. The security model page says short-lived tokens expire no more than 15 minutes after the OIDC flow, that you should treat trusted publishers as if they were API tokens, and that anyone who can commit to the repository without restriction can by default modify a publishing workflow. It recommends per-job permissions, a dedicated environment with required reviewers, tag protection rules where publishing is tag-based, and a publish job with only two steps. It also says publishers are registered to projects, not users, so removing a user does not remove publishers they registered. The page on creating a project with a trusted publisher says a pending publisher does not create a project or reserve its name until it is used, so another user could register the name first.
The topic has had heavy attention this autumn. Posts on X on 21 October 2026, including one from Aikido Security that reached 119,374 impressions and 276 likes at the check, reported that LiteLLM version 1.107.0 on PyPI contained an infostealer. Later posts described how the release pipeline was reached. We did not verify those reports, and this page relies on the PyPI docs for what to do. A 29 October 2026 post from the Python Software Foundation about trusted publishing and SBOMs reached 5,010 impressions.
Measured demand is current. Autocomplete checked on 13 November 2026, about 12:45 AM Australia/Brisbane, returned “pypi trusted publisher”, “pypi trusted publishing github” and “pypi trusted publishing oidc”. A dated YouTube sample the same night found a 26 October 2026 video on the LiteLLM incident (462 views at the check), which is thin on views. An X search of the same window, first page of 9 posts as a lower bound, was dominated by the LiteLLM reports. Counts and suggestions will keep moving.
The checks are written for the next time you set up or change trusted publishing. Always read the current docs first.
Sources: the PyPI trusted publishing docs, the security model, creating a project through OIDC and using a publisher.
What this checklist does and does not do
The honest job of this page is to slow down a publishing change until you know what you trust, the tokens are decided and the exact files are kept, not to certify a package for you. See also the glossary entries for existed no later than and fingerprint.
| Part | What it does | What it does not do |
|---|---|---|
| Current PyPI docs | Reminds you to read the docs and the security model, and to register only a username, repository and workflow you trust. | Configure PyPI for you, or show that your setup matches the docs. |
| Access, environment and tokens | Gives you a reason to check who can change the workflow, give id-token: write at job level, use a reviewed environment and decide about old API tokens. | Show that a package is secure, or that no token was ever exposed. |
| Copies you already hold | Reminds you to keep the exact workflow file, pyproject.toml and the settings you chose. | Show who published a release, or what a past CI run did. |
| A TimeBind of a file you already hold | Records that an exact file existed no later than a recorded time and still matches, using a SHA-256 fingerprint made in your browser. The file stays on your device. | Show that a package or publish was safe. |
If a workflow or release file is one you may need to stand behind later
Before you set up or change trusted publishing:
- Keep a dated copy of the exact publish workflow, pyproject.toml and a screenshot or export of the trusted publisher settings and any environment rules.
- Make a TimeBind of each exact file you already hold. The fingerprint is made in your browser and the file stays on your device. You can later download a Proof of Time Certificate.
- Read the current docs first, and store the files, the docs capture and the certificate together, with a note of when the repository or workflow was last renamed or moved.
A TimeBind shows the exact file existed no later than the recorded time and still matches. It cannot show that a package or a publish was safe.
First Pooled TimeBind free, no card, then from US$5. An ASAP TimeBind is US$15.
What a TimeBind shows, and what it does not. It shows that an exact file existed no later than a recorded time and that a copy shown later still matches its fingerprint. It does not show who made the file, who owns it, that its contents are true, or whether AI was used to make or edit it. This is general information, not legal advice.
PyPI trusted publishing checklist: FAQ
Can this tool show that my PyPI package is secure?
No. The docs describe trusted publishing as a more secure alternative to long-lived API tokens, and say it does not assert the safety of the code or the trustworthiness of its authors. This checklist only helps you pause, check the setup and keep copies.
What is a pending publisher?
A way to configure trusted publishing for a project that does not exist on PyPI yet. The docs say a pending publisher does not create the project or reserve its name until it is used, so if someone else registers the name first, your pending publisher will be unusable.
Why use a GitHub environment?
The security model page says by default anyone who can unconditionally commit to the repository can modify the publishing workflow, and that a dedicated environment with required reviewers can add manual approval. Read the current page for the details.
Should I revoke my old API tokens?
Decide for your own project once trusted publishing works. The docs treat long-lived API tokens as the riskier method, and say trusted publishers should be protected as if they were tokens. Keep a note of what you changed.
What if a maintainer leaves?
The docs say trusted publishers are registered to projects, not users, so removing a user does not remove publishers they registered. Review the project’s publishers as part of offboarding.
Is anything I tick sent to TimeBinder?
No. The checklist runs in your browser. Your ticks stay on the page.
Related guides and tools
- npm trusted publishing checklistThe same job for an npm package
- GitHub Actions workflow lockfile checklistA neighbouring job before you merge a workflow that calls third-party actions
- Cloud coding assistant checklistA checklist before you share a private repo with a cloud assistant
- GitHub Actions CI secret-stealer: what developers should keepWhat to keep if a compromised action is in play
- Developer timestampingThe TimeBinder hub for developer file records
- Source code timestampingDated records for source you already hold
- GlossaryPlain definitions of fingerprint, SHA-256 and existed no later than
- All free toolsPrivate, in-browser tools
Date the exact files you already hold
Add a layer of protection against AI and human fraud and disputes: a dated, checkable record of the exact workflow and settings, kept beside the docs wording you may later need to show.
- Open the app and sign in with email or Google.
- Add your files. They stay on your computer.
- Seal them and download your Proof of Time certificates.
First Pooled TimeBind free, no card, then from US$5. See pricing.