Skip to content

ci: declare workflow-scope permissions on three maintenance workflows#5282

Open
arpitjain099 wants to merge 1 commit into
facebook:mainfrom
arpitjain099:chore/maintenance-workflow-permissions
Open

ci: declare workflow-scope permissions on three maintenance workflows#5282
arpitjain099 wants to merge 1 commit into
facebook:mainfrom
arpitjain099:chore/maintenance-workflow-permissions

Conversation

@arpitjain099
Copy link
Copy Markdown

This patch adds permissions: contents: read at workflow scope to three small workflows that currently rely on the repository default for their workflow GITHUB_TOKEN:

  • .github/workflows/update-cargo-lock.yml
  • .github/workflows/update-yarn-lock.yml
  • .github/workflows/vscode.yml

In all three cases the actual write authority comes from a separately-injected secret, not the workflow token:

  • the two lock-update jobs pass RELAY_BOT_GITHUB_PAT to peter-evans/create-pull-request, so the workflow token only needs to checkout
  • vscode.yml passes VSCE_PAT to vsce publish, same story

So the workflow token only needs contents: read for actions/checkout. Spelling that out makes the contract explicit and means a future change to the repo's default workflow-token scope (or a compromised third-party action like actions-rs/toolchain or peter-evans/create-pull-request, cf. tj-actions/changed-files CVE-2025-30066) can't widen these particular workflows' authority.

Style matches ci.yml (per-job blocks) and docusaurus.yml (workflow-level permissions: contents: write). No behavioural change.

update-cargo-lock, update-yarn-lock and the vscode publish workflow
all run with whatever scope the repository default grants. None of
them rely on the workflow's own GITHUB_TOKEN:

- update-cargo-lock.yml and update-yarn-lock.yml use RELAY_BOT_GITHUB_PAT
  for peter-evans/create-pull-request, so the workflow token only needs
  contents:read for actions/checkout.
- vscode.yml uses VSCE_PAT for vsce publish, so contents:read again
  suffices for the workflow token.

Pinning the read-only scope brings these three in line with ci.yml,
which already declares per-job permissions blocks, and with
docusaurus.yml, which uses a workflow-level permissions block.

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
@meta-cla meta-cla Bot added the CLA Signed label May 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant