ci: declare workflow-level contents: read on 3 workflows

[arpitjain099]

Pins the default GITHUB_TOKEN to contents: read on 3 workflows in .github/workflows/ that don't call a GitHub API beyond the initial checkout.

The following files were left implicit because they reference GITHUB_TOKEN / use a write-scope action / trigger on pull_request_target. Those scopes are best declared by maintainers: metrics.yaml, rustdoc.yaml.

Why

CVE-2025-30066 (March 2025 tj-actions/changed-files supply-chain compromise) exfiltrated GITHUB_TOKEN from workflow logs. Pinning per workflow caps runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is credited per-file by the OpenSSF Scorecard Token-Permissions check.

YAML validated locally with yaml.safe_load on each touched file.

[lnicola]

I think this also needs pull-requests: write

View changes since the review

[lnicola]

Feels like this isn't doing much since it doesn't tighten up the permissions for all workflows (in particular, rustdoc.yaml).

[arpitjain099]

Fair point @lnicola. The reason rustdoc.yaml wasn't included here: its Deploy Docs step uses peaceiris/actions-gh-pages@v4 to push to the gh-pages branch with secrets.GITHUB_TOKEN, which requires contents: write. Declaring permissions: contents: read (the shape used in the other workflows in this PR) would break that step.

A clean fix is workflow-level contents: write on rustdoc.yaml, since the build + deploy run as a single job and only the deploy step needs the write. Practically that doesn't change anything (the same write scope is already in use today via the repo default), it just makes it explicit and pinned, which is what the OpenSSF Scorecard Token-Permissions check looks for per-file.

I held off on declaring write scopes here because I'm an external contributor inferring intent from outside, and that's where I prefer maintainers to make the call. But if you'd like me to roll rustdoc.yaml in with workflow-level contents: write to make this PR cover the full directory, happy to push that. Just say the word.

[lnicola]

I know it needs to write, but I meant that if another token exfiltration attack comes up, these changes won't help much if we still have a workflow with write permissions since it will be targeted instead.

Practically that doesn't change anything (the same write scope is already in use today via the repo default)

I think the default is write-all? But it might be tighter in the rust-lang org, I'm not sure. So yeah, let's make it explicit.