8 ms·

For context, in order to star projects on user's behalf you'd need to request public_repos scope[1], so the UI will look like this: https://github.com/login/oau

For context, in order to star projects on user's behalf you'd need to request public_repos scope[1], so the UI will look like this: https://github.com/login/oauth/authorize?client_id=33a703d019e0d23730ea&scope=public_repo https://github.com/login/oauth/authorize?client_id=33a703d01... (I used a random client_id from google search). As you can notice, the UI does not mention stars at all. [1] public_repo: Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. (https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps https://docs.github.com/en/developers/apps/building-oauth-ap...)

Borgz 4y ago
Wow, this is really bad. The words "read and write" are hidden unless you click on the arrow next to "Repositories". I'm surprised this hasn't been used for malicious purposes until now.
ilyt 4y ago
That [1] is how "ask only for e-mail", "proper" "just" SSO looks like. While sure it isn't immediately expected to access "stars" feature when you give public repo access... ...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.
xgbi 4y ago
> That includes read/write access to code [on public repos owned by the user] What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf. Seriously there should be a big red warning on all scopes apart from the "none" one.
jrochkind1 4y ago
I believe github doens't even have a scope that gives read access but not write access. So we users have been trained to just grant that scope to people who really only need read access, because it's the only thing that works. And in general trained not to even pay attention to those scopes anymore -- on github specifically -- because they are such a mess, and third-parties routinely need scope overreach to do what they want. So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc. Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known. BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...

Borgz 4y ago

Wow, this is really bad. The words "read and write" are hidden unless you click on the arrow next to "Repositories". I'm surprised this hasn't been used for malicious purposes until now.

ilyt 4y ago

That [1] is how "ask only for e-mail", "proper" "just" SSO looks like. While sure it isn't immediately expected to access "stars" feature when you give public repo access... ...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.

xgbi 4y ago

> That includes read/write access to code [on public repos owned by the user] What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf. Seriously there should be a big red warning on all scopes apart from the "none" one.

jrochkind1 4y ago

I believe github doens't even have a scope that gives read access but not write access. So we users have been trained to just grant that scope to people who really only need read access, because it's the only thing that works. And in general trained not to even pay attention to those scopes anymore -- on github specifically -- because they are such a mess, and third-parties routinely need scope overreach to do what they want. So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc. Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known. BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...