SteveYurongSu commented on issue #406: URL: https://github.com/apache/incubator-eventmesh/issues/406#issuecomment-871486080
You may ask "Is it safe to change `pull request` to `pull request target`?" Please see [github-actions-preventing-pwn-requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). > Due to the dangers inherent to automatic processing of PRs, GitHub’s standard pull_request workflow trigger by default prevents write permissions and secrets access to the target repository. However, in some scenarios such access is needed to properly process the PR. To this end the pull_request_target workflow trigger was introduced. > > Like how the introduction of Cross-Origin Resource Sharing (CORS) in the browser security model allowed a web site developer to relax the default Same Origin Policy (SOP), the introduction of pull_request_target trigger allowed a workflow writer to relax some restrictions to a target repository and must be used carefully. The main differences between the two triggers are: > > Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already. > > pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code. > These safeguards enable granting the pull_request_target additional permissions. The reason to introduce the pull_request_target trigger was to enable workflows to label PRs (e.g. needs review) or to comment on the PR. The intent is to use the trigger for PRs that do not require dangerous processing, say building or running the content of the PR. > > **If your workflow scenario simply requires commenting on the PR, but does not require a check out of the modified code, using pull_request_target is a logical shortcut.** > Having said that, mixing pull_request_target with an explicit PR checkout is not always vulnerable. The workflow may, for example: > > * Reformat and commit the code > * Checkout both base and head repositories and generate a diff > * Run grep on the checked out source. > > Generally speaking, when the PR contents are treated as passive data, i.e. not in a position of influence over the build/testing process, it is safe. But the repository owners must be extra careful not to trigger any script that may operate on PR controlled contents like in the case of npm install. The greetings workflow simply requires commenting on the PR, but does not require a check out of the modified code. SO, I think it's safe to change `pull request` to `pull request target`. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
