[no-ci] ci: restrict PR metadata check token to pull-request read access

[arpitjain099]

pr-metadata-check.yml runs on pull_request_target and uses gh pr view --json assignees,labels,milestone to enforce PR hygiene. It only reads PR metadata, no checkout. Adding contents: read (for the implicit checkout if it gets re-added later) plus pull-requests: read (for the gh pr view call) caps the otherwise-inherited token scope on pull_request_target.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[rwgk]

I asked Cursor GPT-5.4 Extra High Fast if read (in general) is sufficient. After fetching a bunch of GHA API documentation, it came back with a "yes", but it isn't sure if the contents: read is actually required.

@arpitjain099: since this workflow only reads PR metadata via gh pr view and does not check out code, do you know whether pull-requests: read alone is sufficient, or whether contents: read is also required?

[arpitjain099]

Good question. The workflow only calls gh pr view, which goes through the REST API and doesn't touch repo contents, so pull-requests: read alone is sufficient. I left contents: read in as future-proofing in case a checkout step ever gets added, but happy to drop it for the minimum scope if you prefer. Either works for the CVE-2025-30066 hardening intent.

[rwgk]

We (that's codex gpt-5.6-sol ultra & rwgk) took a careful second look at this PR, including the workflow's actual API use, GitHub's pull_request_target trust model, and both accidental and adversarial failure modes. We confirmed that the overall change is sound and meaningfully improves the workflow's security posture.

We also confirmed that contents: read is best removed. The workflow does not check out or read repository contents; its only authenticated operation reads PR metadata via gh pr view. Keeping only pull-requests: read therefore matches the current requirement and makes any future need for repository-content access an explicit, reviewable change.

Background considered (optional reading)

General workflow hygiene. Declaring permissions explicitly documents what the job needs, avoids inheriting broader repository defaults, and sets every unspecified configurable permission to none. This is a small, auditable allow-list rather than an implicit grant of authority.

Capability	Before, in the actual latest run	After merge
Read PR metadata	Yes	Yes
Read repository contents via GITHUB_TOKEN	Yes	No
Modify PRs or issues	Yes	No
Push repository contents or create releases	Yes	No
Manage Actions, checks, statuses, or packages	Yes	No

Preventing accidents. A mistaken command or future workflow edit cannot mutate repository state unless someone first expands the declared permissions. The failing authorization then acts as a useful review tripwire instead of allowing an accidental write.

Guarding against attacks. This is meaningful defense in depth, particularly for a pull_request_target workflow. GitHub takes the active workflow and its permissions from the trusted base repository's default branch, so a fork author cannot remove the restriction for their own run merely by changing it in their PR. If an attacker nevertheless gained code execution or stole the job token, that token would remain limited to reading PR metadata and could not promote its own permissions or write to the repository. This does not replace protection of the default branch or prevent code execution itself, but it substantially reduces the damage a compromised job could do.

The current workflow already has a small attack surface: it does not check out or execute PR code, uses no third-party Action, and exposes no separate credential. The explicit minimum permission complements those safeguards by limiting the blast radius of future regressions or supply-chain compromise.

[rwgk]

@arpitjain099 sorry for the long delay, this totally slipped my attention.