Unfortunately, I think this is another indication of a lack of understanding by GitHub of how their OAuth/GitHub App systems are expected to function by end users.
I'm reminded of this incident [1] from a few months ago. Allegedly, a malicious actor abused GitHub's poorly designed OAuth permissions to obtain up to 500 stars from developers without their consent, all thanks to a "sign in with GitHub" button and a flawed consent screen that did not communicate what the victims were consenting to. Even worse, GitHub allegedly decided to suspend at least one victim's account.
We're left with a number of questions:
1. Why does GitHub give third-party apps permission to star repos when it is apparently against the terms of service to automate such an action?
2. Why does GitHub lump this permission in with public_repo, a scope that grants read and write access to all public repositories? [2]
3. Why does the consent UI for this scope display simply as
Repositories
Public repositories
and not even mention that this grants write access unless the user clicks on it? [3] (it also doesn't mention that it gives permission to star repos)
4. Why does GitHub punish victims with account suspension for being tricked into giving consent to malicious apps?
It is good that GitHub is taking some steps to improve account security, such as fine-grained personal access tokens and mandatory 2FA. But these improvements do not seem to be extending to the OAuth system. The GitHub App system, while better in that it has granular permissions, is also flawed with its mysterious "act on your behalf" consent UI. [4] [5]
I'm reminded of this incident [1] from a few months ago. Allegedly, a malicious actor abused GitHub's poorly designed OAuth permissions to obtain up to 500 stars from developers without their consent, all thanks to a "sign in with GitHub" button and a flawed consent screen that did not communicate what the victims were consenting to. Even worse, GitHub allegedly decided to suspend at least one victim's account.
We're left with a number of questions:
1. Why does GitHub give third-party apps permission to star repos when it is apparently against the terms of service to automate such an action?
2. Why does GitHub lump this permission in with public_repo, a scope that grants read and write access to all public repositories? [2]
3. Why does the consent UI for this scope display simply as
and not even mention that this grants write access unless the user clicks on it? [3] (it also doesn't mention that it gives permission to star repos)4. Why does GitHub punish victims with account suspension for being tricked into giving consent to malicious apps?
It is good that GitHub is taking some steps to improve account security, such as fine-grained personal access tokens and mandatory 2FA. But these improvements do not seem to be extending to the OAuth system. The GitHub App system, while better in that it has granular permissions, is also flawed with its mysterious "act on your behalf" consent UI. [4] [5]
[1]: https://news.ycombinator.com/item?id=33917962
[2]: https://docs.github.com/en/developers/apps/building-oauth-ap...
[3]: https://news.ycombinator.com/item?id=33919481
[4]: https://github.com/community/community/discussions/37117
[5]: https://github.com/cirruslabs/cirrus-ci-docs/issues/751