Feedback on the fix to improve security around creation of pull requests in public repos

[willsmythe]

Select Topic Area

Product Feedback

Body

We've shipped a small fix to improve security around creation of pull requests in public repos.

Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.

This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.

Let us know what you think or if you have questions!

[skhomuti]

Just one question - what exactly have you fixed? :)

[Karneades]

Thanks for asking, when reading the "Latest changes" notification I get curious but had the same question also after reading the summary above.

I don't get the security issue with a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization..

[martinlopez799]

pls wrk with me im new computer illitaretr im oldschool well they been doing that to my account through an apple web kit

[sbnewsthailand]

Select Topic Area

Product Feedback

Body

We've shipped a small fix to improve security around creation of pull requests in public repos.

Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.

This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.

Let us know what you think or if you have questions!

[martinlopez799]

they where able to clone my and my momand has all my securtiy in a hub conyrolling and stealing my data ans selling it turough crypto saying hes me cause ge own a computer i oen moto dam ag

[sethvargo]

This change is extremely problematic, especially without any notice to customers or any ability to toggle the behavior. We've lost nearly 2 days (plus the GitHub support team's time) trying to debug why automation workflows are suddenly failing.

We have some very common automation workflows that:

1. Create a branch
2. Do an automated update based on upstream data
3. Commit and push the changes to the branch
4. Open a Pull Request with the changes

A few concrete use cases include keeping a JSON version manifest up to date or a mirroring binary checksums, but there are many.

We also some some additional requirements:

• The bot must have the most minimal permissions on the repositories and organization - it should really only open Pull Requests; we restrict this with fine-grained PATs
• The user that opens the Pull Request must have signed a CLA
• The branch must be in the same repo as the head branch (not a fork), because the Pull Request tests need access to GitHub Actions secrets, and our enterprise policy does not allow GitHub Actions secrets to be included in Pull Requests from forks.
• The Pull Request must run all GitHub Actions CI/CD

None of the proposed workarounds are viable:

• Use the default GITHUB_TOKEN instead of a PAT. This isn't viable because GitHub Actions cannot trigger GitHub Actions. Per GitHub's own documentation:

  If you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of GITHUB_TOKEN to trigger events that require a token.

  This is exactly what we did, but now it's apparently deprecated without notice.

• Fork and push the changes to a bot-owned branch in a fork and create a PR against head in upstream from the fork. As noted above, this is not viable because our enterprise policy does not permit injecting GitHub Actions secrets into forks from Pull Requests. I expect this to be a very common enterprise policy too.

• Create a GitHub App. This is not permitted by company policy.

• Make the bot a member of the organization. This is possible, but not ideal and requires a lot of re-engineering. Our default member policy grants write permissions to all repositories, and we intentionally wanted the bot to have triage permissions. So the bot is currently an outside collaborator. We can fix this–and it seems like it's the only viable option–but the total lack of notice or communication is beyond troubling.

@willsmythe you can see support ticket 2207046 for more information.

[willsmythe]

@sethvargo - sorry for the inconvenience. Because of the potential security risk that existed prior to this change, this was not something we could announce ahead of time (since it would have drawn attention to the problem).

After discussing with the team, we're looking at expanding the logic to also allow members of the repository (i.e. users with any direct or indirect permission on the repository) regardless of their permission level. The expands the exception mentioned in the changelog about organization members to include users that have been granted read, triage, or any other permission to the repository where the pull request is being created. Permission is granted by being added to the repository directly or indirectly via membership in a team.

This would require giving the user triage (or read) permission on the repositories where it needs to create pull requests. Is this viable?

Regarding this:

• If you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of GITHUB_TOKEN to trigger events that require a token.

  This is exactly what we did, but now it's apparently deprecated without notice.

The overall approach is still valid and has not been deprecated. What changed was a particular API (create pull request) for the reasons described in the changelog.

[sethvargo]

Yes - allowing anyone with direct triage permissions would be useful.

[jsoref]

@willsmythe: was this implemented?

[gutwrinch]

I'm not highly skew but I would like to help if there's anything that I could do I'm here

[martinlopez799]

Not yet! i dont care about public repos i just want my github mempool anything under the octocat martinlopez799 ml_tubby mltubby210 thats all my data being used without my permission then selling my data and collecting on me the fukr lives across da street guess i know what needs sweet old school American street justice then

…

On Wed, Feb 14, 2024, 3:40 PM Josh Soref ***@***.***> wrote: @willsmythe <https://github.com/willsmythe>: was this implemented? — Reply to this email directly, view it on GitHub <#57972 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4PYKGVBMNINRS6F3Y4NECTYTUVMLAVCNFSM6AAAAAAZFJ4ZZKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZSG43DG> . You are receiving this because you commented.Message ID: ***@***.***>

[martinlopez799]

Hey Community/Community Support Team how is it that he still on my account developing program if I never did before and without my consent he's been stealing my data and crypto currency from mempool

…

On Wed, Feb 14, 2024, 3:40 PM Josh Soref ***@***.***> wrote: @willsmythe <https://github.com/willsmythe>: was this implemented? — Reply to this email directly, view it on GitHub <#57972 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4PYKGVBMNINRS6F3Y4NECTYTUVMLAVCNFSM6AAAAAAZFJ4ZZKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZSG43DG> . You are receiving this because you commented.Message ID: ***@***.***>