Skip to content

Write the trusted-publisher registration down as the form it is typed into - #71

Merged
ChelseaKR merged 1 commit into
mainfrom
devrel/publisher-registration-values
Sep 7, 2026
Merged

Write the trusted-publisher registration down as the form it is typed into#71
ChelseaKR merged 1 commit into
mainfrom
devrel/publisher-registration-values

Conversation

@ChelseaKR

Copy link
Copy Markdown
Owner

What this is

An audit of this repository's publish path found nothing wrong with it. publish-pypi.yml is correct: dispatch-only; it refuses a tag release.yml has not turned into a published GitHub release; it verifies the tag object, its signature against .github/allowed_signers, and its ancestry on main; it builds at the tagged commit and asserts the artefact filenames carry the tag's own version; and the publish job never checks the repository out, holds id-token: write and environment: pypi and nothing else, so publication is Trusted Publishing over OIDC with no long-lived token stored anywhere. The README is already honest: "The package is not on PyPI yet; a publish-pypi workflow exists and runs only when the maintainer dispatches it."

So this changes one thing only, and it is small: the single action standing between this project and an installable package is now written down as the form it has to be typed into.

What was wrong with it

The workflow header and docs/ROADMAP.md both described the registration in prose — the project must be "registered on pypi.org with this repository, that workflow file and the pypi environment named as its publisher." That is accurate, and it is not the five labelled fields PyPI's Add a pending publisher form asks for. It leaves the one person who can do it reconstructing a form from a sentence.

One of those fields is a genuine trap. Workflow name is the filename (publish-pypi.yml), not the workflow's name: field (publish-pypi). They happen to look alike here, which makes it worse rather than better: get it wrong and PyPI rejects the OIDC claim, and the failure reads as a permissions problem rather than as a typo.

What changed

  • The workflow header and the roadmap's Phase 8 block now carry the five values verbatim, and both say that Workflow name is the filename.
  • The roadmap's free-name claim is re-dated: the name was free on 2026-09-01 and re-checked free today, pypi.org/pypi/ca-tariff-parse/json → HTTP 404. It now also says what "free" means, which the earlier wording left implicit: free is not reserved. Nothing holds that name until the registration is made.
  • A changelog entry saying so.

No workflow behaviour changes. Nothing is published, tagged, or dispatched, and the workflow remains inert until you dispatch it.

Verification

make verify: green. 614 passed, 65 skipped, 93.89% coverage against an 85% floor.

No negative control: the diff is three comment and prose blocks and adds no executable line. The workflow's own guards are unchanged and already covered by the repository's existing tests, and sabotaging a comment to watch a test not fail would prove nothing.

The values, so they are also here

PyPI Project Name:  ca-tariff-parse
Owner:              ChelseaKR
Repository name:    ca-tariff-parse
Workflow name:      publish-pypi.yml
Environment name:   pypi

pypi.org → Your projectsPublishingAdd a pending publisher (the project does not exist on PyPI yet). Afterwards, gh workflow run publish-pypi.yml --ref main -f tag=v0.2.0 publishes the existing signed release. Both steps are yours alone and neither is taken here.

Deliberately not touched

The monetization plan's gates and the weekly tariff-watch job are outside this branch entirely; nothing here reads or changes either.

Prepared with AI assistance; reviewed before submission.

… into

The workflow header and the roadmap described the registration in prose.
PyPI's Add a pending publisher form asks for five labelled fields, and
Workflow name is the filename rather than the workflow's name: field, which
is a mistake that surfaces as a permissions error rather than a typo.

Both now carry the values verbatim. No workflow behaviour changes.
@ChelseaKR
ChelseaKR merged commit aa7f69d into main Sep 7, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant