I realize there are numerous threads open where people are complaining and struggling with the limited permissions granted to PRs from forked repo. I definitely understand there are serious security implications, such as leaking secrets, etc.
What I’m asking here is very narrow: can someone explain why the GITHUB_TOKEN given to a forked repo’s PR can’t have read/write privileges for JUST the
As far as I can tell, the only thing a bad actor could do with that scope is fail his own PR build, or leave an annotation. I’m really struggling to understand why this scope needed to be denied from forks.
What seems so tantalizing is that if this ONE scope were authorized from forks than a ton of basic CI use cases open up for github actions.
I was so close to getting 100% on the GitHub action train – there’s so much to love about them. But for now, if someone asked me about them, I’d tell them what I wish I had known before investing so much time learning them: “they’re great, but you can’t use them for stuff like linting and testing PRs from a forked repo.” …which eliminates the main workflows of massive swaths of the open source community.
Or am I misunderstanding something basic? Is there a key security issue with the
checks scope that I’m not thinking of? Any information would be greatly appreciated.