Permissions list bug

This documentation states that the following scopes are required of a personal access token in order to match the behavior of the GraphQL Explorer:

user
public_repo
repo
repo_deployment
repo:status
read:repo_hook
read:org
read:public_key
read:gpg_key

However, the “repo” scope not only subsumes all of “public_repo”, “repo_deployment”, and “repo:status”, but also includes the additional “repo:invite” scope.  This makes me wonder if the list has a bug in it.  Is this correct?

Thanks for reaching out! And great catch. I’m forwarding this to our documentation team to investigate.

Thanks again!

Thanks again, I’ve had a fast response. The list itself doesn’t have a bug. The repo scope will include those four “sub”-scopes because of the way we normalize them:
https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#normalized-scopes.

I hope this helps!

1 Like

Impressive response time!  And makes sense.  I can see how normalization produces a well-defined and sound list despite the overlap.

In light of the normalization aspect, would it be prudent to replace (in the documentation) the current partially-denormalized list with its canonical normalized form?  Not only would this result in a simpler list, but it would also reduce the risk of confusing users as to what all permissions the listed scopes actually entail.  The latter aforementioned benefit might be reasonably dismissed as merely rooted in user error, but I think the issue constitutes some form of security risk all the same (however small it may seem).  And if nothing else, more streamlined authentication documentation is always a plus for user satisfaction.

1 Like