Github Authentication: Don't require *full repo access* just to view coverage reports

[danielbeardsley]

Background

I'm a member of a team in a github org, we use coveralls to report coverage results on each pull.

Problem

In order to view coverage reports, coveralls wants full access to all my public and private repos. This is far more access than is needed to simply verify I'm a member of the team and thus should be allowed to view the report.

"Full access to all public and private repos" is practically the keys to the kingdom, If this permission isn't needed, then the software shouldn't ask for them. If it is needed, I think the community needs an explanation about why this app needs to be able to read and write to all your repos just to view a report.

[afinetooth]

Hi, @danielbeardsley.

Thanks. I've added your request to the card in our backlog related to changing our integration method (see below).

Things are this way because we use a Github OAuth app for our integration with Github and, unfortunately, that limits us to using the repo scope, defined here.

We're aware this is not ideal and we do plan to release a Github App based integration later this year. We're just heavily invested in our legacy integration, so it's a big effort and we're not there yet.

[danielbeardsley]

Things are this way because we use a Github OAuth app for our integration with Github and, unfortunately, that limits us to using the repo scope

This is stated in a weird way. I think you're saying that OAuth apps can't check if you have access to a repo without getting the repo scope. The docs seem to support this:

You must authenticate using an access token with the read:org and repo scopes with push access to use this endpoint. GitHub Apps must have the members organization permission and metadata repository permission to use this endpoint. -- The docs

I'm still aghast that it's been this way for years and there aren't enough complaints.

Looks like you could use the Teams API to validate team membership or the Org API to validate org membership, all with read-only scopes.

[afinetooth]

I understand. We're a very small outfit and, as I say, the biggest effort for us in switching is supporting both integrations while offering an opt-in migration path for "legacy" repos.

[abo-abo]

Bumping the issue as our organization is affected by this as well.