-
Notifications
You must be signed in to change notification settings - Fork 79
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
feat: support forks in e cherry-pick
#345
Conversation
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.
Haven't reviewed the actual code, but amusingly I don't actually think we want this to work.
A large part of e cherry-pick
is the follow up patch conflict fix that only works for maintainers (not forks).
@MarshallOfSound, does I think there's a real use-case for non-maintainers to want to use |
I don't believe maintainer_can_modify allows apps to push to your fork (untested) but the actual issue is the app token won't be provided to the forked CI build for security reasons. So it won't have a token to push it, I'd hate to make it easy for these PRs to be made only for 80% of them to need to be rebased / conflict merged anyway. |
The following assumes Could we redesign PatchUp bot a bit to make this viable? I don't have the full picture here, but from what I've scrapped together, what if the bot listened to CircleCI webhooks looking for jobs failing, then it gets the artifacts for the job, looks for the |
@dsanders11 There is no webhook, it all happens from the CI machine. https://github.com/electron/electron/blob/main/.circleci/build_config.yml#L279-L302
This would be a potential security hole as it would allow a forked PR to apply an arbitrary git patch coming from an authenticated user (in this case a github app) which on various systems may be considered trusted. I'm relatively confident in saying there's no safe way to do this without drastic rewrites / rearchitectures of how we do cherry picks. It's unfortunate but the reality is we can't afford forks the same level of trust / ease of use as our maintainer branches 🤷 |
Also in a similar vein.
We are actively trying to reduce the usage of that account and replacing it with much more scoped GitHub apps where we can |
Yes, I know it doesn't currently use a webhook, I was suggesting it could be changed to.
@MarshallOfSound Can you expand on this? Not sure I follow what the security risk would be there. The commit would be made on the fork's branch, and they're already giving permission to allow maintainers to make commits there. Is the concern that the commit would be originating from the GitHub app, which makes it look trusted to Electron infra stuff? With "squash and merge" isn't that commit just an implementation detail which will fall away once merged? If the concern is the author of the commit, could a separate, considered untrusted, GitHub app make those commits for forks? |
@MarshallOfSound do we still want to move this forward potentially? or is this DOA given the above security constraints/considerations? |
Unless someone spends the time making |
Since |
@dsanders11 |
@MarshallOfSound oh, that did indeed confuse me. Does |
Nope, it's literally a single JS file in e/e https://github.com/electron/electron/blob/main/script/push-patch.js |
Closes #318.