ci: declare workflow-level contents: read on the 9 python-N.yml build workflows

[arpitjain099]

Pins the default GITHUB_TOKEN to contents: read on the per-Python-version build workflows: python-37.yml through python-315.yml. Each runs sphinx-build against the translated rst files and uploads the rendered HTML as a workflow artifact, with no GitHub API mutation.

Why

CVE-2025-30066 (March 2025 tj-actions/changed-files supply-chain compromise) exfiltrated GITHUB_TOKEN from workflow logs and the leaked token retained whatever scope was issued at the workflow level. Pinning per workflow caps that 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.

[rffontenelle]

None of this project's workflows use tj-actions/changed-files

[rffontenelle]

Considering that the reason for the PR doesn't match the repository and I received no reply, I'm unable to move forward with the proposal. I can't help to think this is is a job of AI. Hence, I'm closing this pull request.

[arpitjain099]

Hey @rffontenelle, sorry for the delay and for the PR not framing itself well enough up front. We've all been fairly heads-down on actual supply-chain incidents lately (myself included). Friday was a long work day on that front, and I'm in Japan so by the time your first comment came in I was already AFK for the weekend. Not AI generated, just bad timing on the response.

On the substance you're right, no workflow in this repo currently uses tj-actions/changed-files. The PR isn't claiming a fix for that specific action. CVE-2025-30066 is the motivating example for a broader hardening, not the specific bug being patched: when a third-party action is supply-chain compromised, the damage equals whatever scope GITHUB_TOKEN was issued with at the workflow level. The tokens leaked in that incident weren't dangerous because of the action itself, they were dangerous because most calling workflows ran with the default "Read and write" repository token, so the leaked token could push commits, edit PRs, edit releases.

The 9 workflows here each pull in third-party actions (actions/checkout, actions/cache, actions/setup-python, sphinx and msgfmt). Any of those, or anything they transitively pull in, could be the next tj-actions. permissions: contents: read at the workflow level means: even if that happens, the token leaked from a compromised action can only read this public repo's content. It can't push to gh-pages, edit PRs, or touch anything else in the python org. No functional change to the workflows themselves; the build still produces the same artifact.

This is also what the OpenSSF Scorecard Token-Permissions check evaluates (per-file, so implicit defaults score zero on each unhardened file), which is one practical signal the project picks up by declaring scopes explicitly.

If the project's stance is "we don't want preventive hardening on workflows that aren't currently broken", close is the right call and I respect that. If it was more "the PR didn't explain its rationale well enough", happy to amend the body and have it reopened. Either way, sorry again for the delayed response.

[arpitjain099]

One more bit on the timing piece: I contribute to open source on my own time (no employer behind it), so my response cadence depends on what evenings and weekends look like in JST. The gap between your first comment (2026-05-14 23:29 UTC) and the close (2026-05-15 16:11 UTC) was under 17 hours, which mostly overlapped my work day plus sleep here. That's not really enough of a window for a volunteer in a different timezone to see the notification, evaluate the question, and write a substantive reply.

Not asking to reverse the close, that's your call as maintainer. Just a small request for future "no reply" closures on volunteer-contributor PRs: a few days of latency before closing would give better odds of an actual reply landing first. We're all spinning the OSS wheel on personal time on both sides.