While reviewing #113, I noticed that the eps1lon/actions-label-merge-conflict action started recommending setting explicit permissions as of its v3.1.0 release (eps1lon/actions-label-merge-conflict#151), which this repository does not currently do. It occurred to me that there might be some opportunities to improve the permissions of the other workflows as well.
Currently, only the pr-comment and publish-wiki workflows declare an explicit permissions block, and they do so only at the job level. The remaining workflows (basic-qa, label-merge-conflicts, label-new-prs, and label-remove-outdated) rely on the default token permissions, which can be broader than what each job actually needs.
Opening this issue to suggest reviewing the permissions across all workflows and adopting a least-privilege pattern. Maybe we could add a top-level permissions: {} block in each workflow file that grants no permissions by default, with each job declaring only the specific permissions it needs (inspired by https://developer.wordpress.org/coding-standards/wordpress-coding-standards/github-actions/#excessive-permissions).
While we are at it, I wonder if it would be a good idea to add a tool like Zizmor and/or Actionlint to the CI. They could catch this kind of issue (and other workflow security and correctness problems) automatically, instead of relying on a manual review.
While reviewing #113, I noticed that the
eps1lon/actions-label-merge-conflictaction started recommending setting explicit permissions as of its v3.1.0 release (eps1lon/actions-label-merge-conflict#151), which this repository does not currently do. It occurred to me that there might be some opportunities to improve the permissions of the other workflows as well.Currently, only the
pr-commentandpublish-wikiworkflows declare an explicitpermissionsblock, and they do so only at the job level. The remaining workflows (basic-qa,label-merge-conflicts,label-new-prs, andlabel-remove-outdated) rely on the default token permissions, which can be broader than what each job actually needs.Opening this issue to suggest reviewing the permissions across all workflows and adopting a least-privilege pattern. Maybe we could add a top-level
permissions: {}block in each workflow file that grants no permissions by default, with each job declaring only the specific permissions it needs (inspired by https://developer.wordpress.org/coding-standards/wordpress-coding-standards/github-actions/#excessive-permissions).While we are at it, I wonder if it would be a good idea to add a tool like Zizmor and/or Actionlint to the CI. They could catch this kind of issue (and other workflow security and correctness problems) automatically, instead of relying on a manual review.