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

[arpitjain099]

Adds workflow-level permissions: contents: read to four workflows: callUpdateTarget, htmlvalidator, pr-checks, version-increments. None call the GitHub API beyond checkout.

Same post-CVE-2025-30066 (tj-actions/changed-files) hardening pattern. YAML validated locally.

[HannesWell]

Is it really necessary on jobs that just call other workflows?
Wouldn't it be sufficient to specify the permissions on the called workflows (which most but not all do).

Furthermore in this case, wouldn't this break some of the called workflows? IIRC it isn't possible to elevate the permissions?

[arpitjain099]

Good catch @HannesWell, thanks. You're right on both counts: pr-checks.yml, callUpdateTarget.yml, and version-increments.yml are all just callers of reusable workflows, and capping permissions at the caller would intersect with whatever the callees need. I reverted those three back to upstream and kept the change only on htmlvalidator.yml which actually runs work itself.

Force-pushed. Let me know if the reduced scope still makes sense, or if you'd rather close.

[HannesWell]

Force-pushed. Let me know if the reduced scope still makes sense, or if you'd rather close.

Thanks for the update. Generally it totally makes sense to use only the minimal permissions. I'll have a look at it in detail probably not before the end of the week (we are currently in the final release phase, which is very busy).

Besides this, I think there are a few more 'leave' workflows that don't have their permissions minimized. Could you check and update them too as appropriated?

[arpitjain099]

Thanks, and no rush given the release phase. I went through the other leaf (directly-triggered) workflows and extended the PR to the ones that can be safely minimized:

• htmlvalidator.yml: contents: read (read-only validation on PRs)
• pr-checks.yml: contents: read + issues: read. It is purely an orchestrator, and that is the minimal union its reusables declare (checkVersions is {}, verifyFreezePeriod needs issues: read, checkMergeCommits needs contents: read), so no write scope is required.
• licensecheck.yml: top-level contents: read as the default; the call-license-check job keeps its explicit pull-requests: write.

I deliberately left two leaves alone: callUpdateTarget.yml and version-increments.yml. Both delegate to reusables that create PRs / push via a bot PAT (RELENG_BOT_PAT, PLATFORM_BOT_PAT), so the right minimal GITHUB_TOKEN scope there depends on how much the workflow relies on the PAT vs the default token, which you would know better than me. Happy to take a stab at those too if you would like. The reusable (on: workflow_call) workflows are also untouched on purpose, since their permissions intersect with caller grants.