feat: add authorize-commenter action

[cryptodev-2s]

Workflows triggered by issue_comment run from the default branch with access to secrets. The two in MetaMask/core that use them, update-changelogs and publish-preview, gate only on the comment body, so on a public repository anyone who can comment can start them. publish-preview publishes to npm. There is nothing shared to check the commenter, so today each workflow would have to grow its own copy of the check.

This adds an authorize-commenter action. It reads the commenter's repository permission and fails unless that permission is write or admin. A workflow runs it as its first job and gives every privileged job needs on that job, so a refusal skips them.

A few notes on the choices:

• It fails rather than returning an authorized output. Action outputs are strings, and every non empty string is truthy in a workflow expression, so a consumer writing the natural if: needs.authorize.outputs.authorized would get 'false' and a wide open gate. Failing removes the trap instead of documenting around it, and it means the integration is just needs, with no condition to forget.
• It uses the permission API rather than github.event.comment.author_association. The association returns NONE for org members whose membership is private, and its COLLABORATOR value does not distinguish a read only collaborator from one who can push.
• The permission field collapses custom roles onto admin, write, read and none, so admin and write are exactly the logins that can push. Everyone else reads back as read on a public repository and none on a private one.
• The default GITHUB_TOKEN is enough. I was unsure whether that endpoint would need a token minted by get-token, so I tested it: with only contents: read it reads write for a maintainer and read for octocat. See the run on this pull request.

test-authorize-commenter.yml covers both directions, a login with write access being authorized and octocat being refused. It triggers on pull_request directly rather than through workflow_call like the other test-*.yml workflows, because those are not wired into main.yml and so never run. The positive case is skipped on fork pull requests, where the author legitimately has read access.

Worth knowing for whoever adopts this: it authorizes the person who wrote the comment, not the code they wrote it on. A workflow that passes this gate and then checks out the pull request head or merge ref runs untrusted code with exactly the privileges the gate was protecting. That caveat is in the action description too.

Adoption in MetaMask/core will be a separate pull request covering both workflows. See MetaMask/core#10077, where this came up.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d30ca1c. Configure here.}

[cursor]

Bot PRs fail write-access test

Low Severity

The write-access step treats github.actor as a collaborator with push rights on every non-fork pull request. Same-repository bot PRs, including Dependabot, usually get none from the permission API, so that step fails and the new check goes red.

 

^{Reviewed by Cursor Bugbot for commit d30ca1c. Configure here.}