ci: add automatic PR labeling based on changed files#761
ci: add automatic PR labeling based on changed files#761manzil-infinity180 wants to merge 2 commits intoin-toto:mainfrom
Conversation
Signed-off-by: Rahul Vishwakarma <rahulvs2809@gmail.com>
Signed-off-by: Rahul Vishwakarma <rahulvs2809@gmail.com>
✅ Deploy Preview for witness-project ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Kusari Analysis Results:Caution Flagged Issues Detected The dependency analysis found no issues. However, the code analysis identified a HIGH severity concern in .github/workflows/labeler.yml: the use of the pull_request_target trigger grants base-repository-level permissions to workflows triggered from forks. Combined with the pull-requests: write permission, this creates a potential privilege escalation attack vector if any workflow step checks out or executes code from the PR branch (head ref). The full job steps were not available for review, making it impossible to confirm the workflow is safe. Action items before proceeding: (1) Confirm no actions/checkout step references the PR head sha or head ref. (2) If labeling fork PRs is not required, switch to the safer pull_request trigger. (3) If pull_request_target is intentionally used, add explicit documentation in the workflow file confirming no PR branch code is checked out or executed. The PR should be held until one of these mitigations is verified and documented. Note View full detailed analysis result for more information on the output and the checks that were run. Required Code Mitigationspull_request_target grants base-repo-level permissions to workflows triggered from forks. If the labeler only reads configuration from the base repository and never checks out or executes code from the PR branch, this can be acceptable. However, you must explicitly ensure that no actions/checkout step references the PR head ref (e.g., ref: ${{ github.event.pull_request.head.sha }}). If checkout of PR code is not needed, the current pattern may be acceptable but should be documented. If labeling fork PRs is not required, switch to the safer pull_request trigger. If pull_request_target is necessary, add a comment to document the intentional use and confirm no PR branch code is executed.
Found this helpful? Give it a 👍 or 👎 reaction! |
![kusari-inspector[bot]](https://avatars.githubusercontent.com/in/1220830?s=60&v=4){kind=small}
| name: PR Labeler | ||
|
|
||
| on: | ||
| pull_request_target: |
There was a problem hiding this comment.
Issue: pull_request_target grants base-repo-level permissions to workflows triggered from forks. If the labeler only reads configuration from the base repository and never checks out or executes code from the PR branch, this can be acceptable. However, you must explicitly ensure that no actions/checkout step references the PR head ref (e.g., ref: ${{ github.event.pull_request.head.sha }}). If checkout of PR code is not needed, the current pattern may be acceptable but should be documented. If labeling fork PRs is not required, switch to the safer pull_request trigger. If pull_request_target is necessary, add a comment to document the intentional use and confirm no PR branch code is executed.
Recommended Code Changes:
on:
pull_request_target:
types: [opened, synchronize, reopened]
# IMPORTANT: pull_request_target is used intentionally to allow labeling fork PRs.
# This workflow MUST NOT checkout or execute any code from the PR branch (head ref).
# Ensure actions/checkout is not used with the PR head sha or head ref.
There was a problem hiding this comment.
pull_request_target is used intentionally to allow labeling fork PRs 👀
|
I noticed @matglas was adding labels like documentation and bug manually on PRs; this should help automate the file-path-based ones.
|
1 participant
What this PR does / why we need it
Description
Adds a GitHub Actions workflow using actions/labeler@v5 to automatically label PRs based on which files are changed (e.g., documentation, attestors, signers, cli, policy, etc.)
Which issue(s) this PR fixes (optional)
(optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when the PR gets merged)*Fixes #
Acceptance Criteria Met
Special notes for your reviewer: