publish.yml can publish from any branch or tag: the pypi environment has no deployment policy and the tag input is used as-is #10

Versions: python-library-template 8ebf45d, Copier 9.18.2

Any ref can publish to PyPI. The workflow_dispatch trigger in template/.github/workflows/publish.yml.jinja:7-11 takes a free-text tag, and both jobs check out whatever it says (:30, :37, :60): a branch, any tag, or a SHA. The dispatch can also start from any branch, and GitHub then runs that branch's own copy of publish.yml, including any checks someone removed from it. The PyPI Trusted Publisher depends on the pypi environment for protection, and scripts/setup_repo.py:89 creates that environment with a bare PUT. It has no required reviewers and no deployment branch or tag policy. The only ruleset the script creates covers the default branch (scripts/setup_repo.py:156-163, ~DEFAULT_BRANCH), so release tags are unprotected as well. So anyone who can push a branch and start a workflow can publish any content under the library's name.

Also, id-token: write is granted to the whole workflow (publish.yml.jinja:13-15), so the check job can mint an OIDC token too, even though it only resolves a tag name. PyPI rejects that token as long as the Trusted Publisher names the pypi environment, so this is least privilege rather than a hole. Still, that job has no use for the token.

Reproduction

The libraries are configured by this script, so their live settings show what it produces:

for r in idempotency-kit clientwright deadline-budget; do
  gh api repos/bedrock-python/$r/environments/pypi \
    --jq '"pypi env: protection_rules=\(.protection_rules) policy=\(.deployment_branch_policy)"'
  gh api repos/bedrock-python/$r/rulesets --jq '.[] | "ruleset \(.name) target=\(.target)"'
  id=$(gh api repos/bedrock-python/$r/rulesets --jq '.[] | select(.name=="master-rules") | .id')
  gh api repos/bedrock-python/$r/rulesets/$id --jq '"bypass=\(.bypass_actors) include=\(.conditions.ref_name.include)"'
done

# where the existing manual publishes were dispatched from
gh api "repos/bedrock-python/sqlalchemy-foundation-kit/actions/workflows/publish.yml/runs?event=workflow_dispatch" \
  --jq '.workflow_runs[] | "\(.head_branch) \(.conclusion) \(.created_at)"'

Actual

The same output for all three libraries:

pypi env: protection_rules=[] policy=null
ruleset master-rules target=branch
bypass=[] include=["~DEFAULT_BRANCH"]

master success 2026-08-28T15:12:15Z
sqlalchemy-foundation-kit-v0.2.0 failure 2026-08-28T15:08:37Z
master success 2026-05-19T14:56:25Z
master success 2026-05-19T14:54:33Z

All ten successful manual publishes in the org were dispatched from master, with the tag passed as the input. With deployment_branch_policy: null, a job from any ref can use the environment. I did not dispatch a publish from a scratch branch to prove it, because that would upload to PyPI.

Why

With Trusted Publishing, PyPI trusts "this workflow file, in this repository, deploying to this environment" instead of a stored token. When the environment has no policy, that means any branch of the repository, which is much less than what the environment: pypi line in setup_repo's output suggests. A version on PyPI cannot be replaced, only yanked.

Proposal

• In setup_repo.py, create pypi with a custom deployment policy: PUT environments/pypi with {"deployment_branch_policy": {"protected_branches": false, "custom_branch_policies": true}}, then POST environments/pypi/deployment-branch-policies for {"name": "master", "type": "branch"} (the workflow_run path runs with the default branch as its ref) and {"name": "<slug>-v*", "type": "tag"}. Optionally, add the maintainer as a required reviewer.
• The environment policy is not enough while the tag input exists. A dispatch from master passes the policy and still checks out whatever ref the input names. Drop the input, dispatch publishes from the tag itself (gh workflow run publish.yml --ref <slug>-vX.Y.Z), and have the check job require github.ref_type == 'tag' and a tag matching the release pattern before it uses github.ref_name.
• Consider a tag ruleset on <slug>-v*, as long as Release Please's token can still create its tags.
• Move id-token: write from the workflow to the publish job, and leave the workflow-level permissions at contents: read.