Simplify access requests with `repo:status` instead of `repo`

[hybridherbst]

Feature Request

Description

Currently, using github-oauth-ui requires a very high level of permissions for granular repo access, namely the repo scope:

Grants full access to repositories, including private repositories. That includes read/write access to code, commit statuses, repository and organization projects, invitations, collaborators, adding team memberships, deployment statuses, and repository webhooks for repositories and organizations. Also grants ability to manage user projects.

This is scary, and rightfully so! It shows a big warning when people click on "Login" that whoever requested the login will gain very permissive access rights that are actually not needed.

I believe it was necessary at the time of implementation because this was the only scope available for repos, but by now there's (I believe) a new one that might be sufficient - repo:status:

Grants read/write access to commit statuses in public and private repositories. This scope is only necessary to grant other users or services access to private repository commit statuses without granting access to the code.

Suggested implementation

Use repo:status instead of repo oauth scope

Possible alternatives

Alternative thing to try could be repo_deployment.

[n4bb12]

It's broad, yes, but if we're talking private repositories, that's the only scope available. repo:status refers to public repositories.

The token is shared with your Verdaccio instance and stored on the signed-in person's machine (browser and/or npm config). Both verdaccio and this plugin are open source. You have full control over everything you install and configure on your instance.

If you still find that scary, I'm afraid I can only recommend using a different authorization mechanism.

[n4bb12]

Of course, I'm open if you have any more ideas on how to reduce the requested scope.

[hybridherbst]

The description of repo:status mentions both public and private repositories.

Just to clarify: it isn't scary when used inside an organization - it's scary for other people. Our usecase is giving other people (outside our org) access to packages based on which GitHub repos they have read and issue access to. If must be we can of course change the auth mechanism but if there's a way to reduce the required scope that's preferred.

[n4bb12]

Maybe I'm misunderstanding how repo:status works. I'll try it out and see if I can make it work.

[n4bb12]

I tried repo:status and repo_deployment but neither of them grant visibility to private repositories.

The way I understand the docs, they only grant visibility to commit and deployment statuses, respectively, i.e. repository-related data, but not to the repository itself. Hence private repositories are not included if you fetch a list of repositories.

[n4bb12]

Maybe we could offer using an owner token as an opt-in config option.

Instead of using the signed-in user token and check user-->repositories, we could use a token created by the org/repo owner and check repository-->users. It would require additional configuration for the registry owner but we would not need to request anything from the registry end users, except public information.

[n4bb12]

It's just an idea, I'm not sure if it would work in combination with how Verdaccio relies on groups, but maybe we can make it work somehow.

[hybridherbst]

Do you happent to know if this would work if the users are external collaborators and not team members? Sounds interesting – and I wouldn't mind extra configuration steps

[n4bb12]

I would assume it does because the repo owner (and hence the configured token) can see and change who is a collaborator on the GH website.

[n4bb12]

Implemented in https://github.com/n4bb12/verdaccio-github-oauth-ui/releases/tag/5.0.0. Note that this is a major release that introduces some breaking changes.