lupyuen commented on issue #18359: URL: https://github.com/apache/nuttx/issues/18359#issuecomment-3868830855
_Does pr-size-labeler work with (safer) pull_request, instead of (unsafe) pull_request_target?_ Nope! When we changed the trigger from (unsafe) pull_request_target to (safer) pull_request... https://github.com/lupyuen7/nuttx/blob/master/.github/workflows/labeler.yml#L17 <img width="994" height="802" alt="Image" src="https://github.com/user-attachments/assets/05a752cc-5ab3-4436-87a9-b7a11bfc0ba8"; /> The Labeler Workflow fails, even though we have `pull-requests: write` and `issues: write` token permissions... https://github.com/lupyuen7/nuttx/actions/runs/21809066491/job/62917607595 <img width="1371" height="961" alt="Image" src="https://github.com/user-attachments/assets/467db5f1-9102-4472-b62d-70414dc5adba"; /> That's because the Labeler Action runs on a PR from a Forked Repo, which requires pull_request_target... https://github.com/actions/labeler?tab=readme-ov-file#recommended-permissions > However, when the action runs on a pull request from a forked repository, GitHub only grants read access tokens for `pull_request` events, at most. If you encounter an `Error: HttpError: Resource not accessible by integration`, it's likely due to these permission constraints. To resolve this issue, you can modify the `on:` section of your workflow to use [`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) instead of `pull_request` (see example [above](#create-workflow)). This change allows the action to have write access, because `pull_request_target` alters the [context of the action](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) and safely grants additional permissions. And pull_request_target has security concerns... https://github.com/actions/labeler?tab=readme-ov-file#recommended-permissions > There exists a potentially dangerous misuse of the `pull_request_target` workflow trigger that may lead to malicious PR authors (i.e. attackers) being able to obtain repository write permissions or stealing repository secrets. Hence, it is advisable that `pull_request_target` should only be used in workflows that are carefully designed to avoid executing untrusted code and to also ensure that workflows using `pull_request_target` limit access to sensitive resources. Refer to the [GitHub token permissions documentation](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) for more details about access levels and event contexts. (Then why would GitHub allow us to run an Unsafe Labeler? Sigh) Lemme explore the solutions suggested in the earlier comments... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
