-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issue with workflow on forks #99
Conversation
This allows the add-to-project workflow to work on forks.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On reopened would a duplicate issue be created?
@@ -6,7 +6,7 @@ on: | |||
- opened | |||
- reopened | |||
- transferred | |||
pull_request: | |||
pull_request_target: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've heard a fair bit about secret exfiltration from repositories using this feature, but I don't know the details. Does allowing forks to access our secrets in this way potentially expose those secrets to code in the fork? Are the tokens here allowed to do anything sensitive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed it with @rubensf who confirmed those issues don't apply in this case, and this is safe to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See also the TL;DR from here:
Combining
pull_request_target
workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.
We aren't doing any checkout here, and are using pull_request_target
for its intended purpose: to process PRs safely. Also from that page:
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.
This automation doesn't create issues, it just adds them to the project, and an issue cannot be added twice. See this test issue if you want to try it out yourself. |
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
See connectrpc/connectrpc.com#99 for more context
This allows the add-to-project workflow to work on forks.