Skip to content

pages.yml: move pages:write / id-token:write from workflow level to the deploy job #66

Description

@hyperpolymath

Flagged by SonarCloud as a MAJOR vulnerability; deferred from #64 as untestable there.

Finding

.github/workflows/pages.yml declares at workflow level:

permissions:
  contents: read
  pages: write
  id-token: write

Both jobs therefore inherit all three. The build job only needs contents: read — it
checks out, compiles Ddraig inside a container and uploads an artifact. It has no reason
to hold Pages deploy credentials or the ability to mint an OIDC token, yet it is the job
that runs a compiler over checked-out source.

Suggested shape

permissions:
  contents: read          # workflow floor

jobs:
  build:
    permissions:
      contents: read
  deploy:
    permissions:
      pages: write
      id-token: write

Why it was not fixed in #64

Pages deployed successfully on 2026-07-27 for the first time since 07-19 — the site went
from a long-standing 404 to HTTP 200. The deploy job does not run on pull requests,
so a permissions restructure could not have been verified inside #64; it would only have
been observable after merging to main. Changing the credentials of a deployment that had
been broken for eight days and had just started working, without a way to test it first,
is the same untestable-change trap declined in #61.

How to verify when doing it

pages.yml has workflow_dispatch, so after merging:

gh workflow run pages.yml --ref main
gh run list --workflow=pages.yml --limit 1
curl -o /dev/null -w "%{http_code}\n" https://hyperpolymath.github.io/statistikles/   # expect 200

Revert immediately if the deploy job fails to mint its token.

Metadata

Metadata

Assignees

No one assigned

    Labels

    cicdCI/CD: workflows, actions, lockfiles, pins, runners, release gates

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions