ci: declare least-privilege workflow-level contents: read#23653
Conversation
davsclaus
left a comment
There was a problem hiding this comment.
Thanks for the security hardening effort — least-privilege workflow tokens are a great practice, especially after the tj-actions incident.
However, two of the three workflows perform write operations that will break with only contents: read, because all unspecified permissions default to none when any permissions: key is declared.
pr-commenter.yml calls github.rest.issues.createComment() (line 87) to post a welcome comment, and downloads artifacts via the Actions API. It needs pull-requests: write and actions: read.
pr-labeler.yml uses actions/labeler (line 67) to add labels to PRs, and also downloads artifacts. It needs pull-requests: write and actions: read.
pr-id.yml is fine with just contents: read — it only checks out code and uploads an artifact.
For pr-commenter.yml and pr-labeler.yml, the permissions block should be:
permissions:
contents: read
pull-requests: write
actions: readThis review covers project conventions and correctness. It does not replace specialized review tools such as CodeRabbit, Sourcery, or SonarCloud.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
These three workflows currently inherit the default read-write GITHUB_TOKEN. Declare explicit workflow-level permissions instead. pr-id only checks out the repo and uploads an artifact, so contents: read is enough. pr-commenter and pr-labeler both download the PR id artifact through the Actions API (actions: read); pr-commenter then posts a welcome comment via github.rest.issues.createComment and pr-labeler runs actions/labeler, both of which write to the PR (pull-requests: write). Scopes were matched to what each workflow actually does, per review feedback. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
9e5fe87 to
1deb423
Compare
davsclaus
left a comment
There was a problem hiding this comment.
The requested changes have been correctly applied — all three workflows now declare the right permissions:
- pr-id.yml:
contents: read(checkout + upload artifact only) - pr-commenter.yml:
contents: read+pull-requests: write+actions: read(artifact download + PR comment) - pr-labeler.yml:
contents: read+pull-requests: write+actions: read(artifact download + PR labeling)
Thanks for addressing the feedback promptly.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Hardens 3 workflow(s) in this repo by declaring a workflow-level
permissions: contents: read. Today those workflows inherit the legacy broad read-write GITHUB_TOKEN; the read-only default reduces blast radius if any step is compromised.I checked each file - they read the checkout and run tests/lints; no GitHub API writes (no
gh pr/issue, nogit push, no release/publish/comment actions). So behavior is unchanged.Reference: the tj-actions/changed-files compromise (CVE-2025-30066) is the canonical reason to apply least-privilege defaults.