Declare build.yml's token reach in build.yml #106

Merged
JMR-dev merged 2 commits from ci/build-workflow-permissions into main 2026-08-25 20:49:19 +00:00
JMR-dev commented 2026-08-25 15:16:10 +00:00 (Migrated from github.com)

Closes #100 — the only open CodeQL alert on this repository.

build.yml declares permissions in exactly one place, the release job's contents: write, and has no top-level default — so the test job inherits the repository setting.

Nothing is over-privileged today, and the commit says so

The repository default is already read (default_workflow_permissions: read, read from the API rather than assumed). The test job holds a read token now. This is hygiene — a change implying it closed a live hole would be overstating it.

What it buys is that the default cannot widen these jobs later without someone editing this file. That's not invented for the occasion — it's the argument status_check.yml already makes, and it names this file:

the token's reach should be readable here, and a default that widens later should not silently widen these jobs with it. build.yml's release job makes the opposite declaration for the same reason.

Verified the thing that would actually break

The release job's contents: write still wins — top level is a default, not a ceiling:

top-level:  contents: read
  test      inherits → contents: read
  release   contents: write

The ticket's mutation found something

Deleting the release job's contents: write leaves actionlint green and CodeQL quiet — a narrower permission isn't an alert. Nothing would catch it until a tagged release failed to publish. Filed separately rather than fixed here.

actionlint clean at the pinned digest. Comment and permissions only.

Closes #100 — the only open CodeQL alert on this repository. `build.yml` declares permissions in exactly one place, the `release` job's `contents: write`, and has **no top-level default** — so the `test` job inherits the repository setting. ## Nothing is over-privileged today, and the commit says so The repository default is already `read` (`default_workflow_permissions: read`, read from the API rather than assumed). The test job holds a read token now. **This is hygiene** — a change implying it closed a live hole would be overstating it. What it buys is that the default **cannot widen these jobs later** without someone editing this file. That's not invented for the occasion — it's the argument `status_check.yml` already makes, and it names this file: > the token's reach should be readable here, and a default that widens later should not silently widen these jobs with it. **build.yml's release job makes the opposite declaration for the same reason.** ## Verified the thing that would actually break The release job's `contents: write` still wins — top level is a default, not a ceiling: ``` top-level: contents: read test inherits → contents: read release contents: write ``` ## The ticket's mutation found something Deleting the release job's `contents: write` leaves **actionlint green and CodeQL quiet** — a *narrower* permission isn't an alert. Nothing would catch it until a tagged release failed to publish. Filed separately rather than fixed here. actionlint clean at the pinned digest. Comment and permissions only.
Sign in to join this conversation.