Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub's Permission System is Flawed #113

Open
zenorocha opened this Issue Feb 11, 2016 · 69 comments

Comments

Projects
None yet
@zenorocha
Copy link
Contributor

zenorocha commented Feb 11, 2016

This is an open letter to @github on behalf of third-party app developers.

For a very long time, permission scopes has been a common issue for both users and app developers.
These scopes are extremely permissive and far too broad, preventing users from using third-party applications.

We need a more granular permission system and we hope you listen to this.

Below you can find some examples that describes exactly what we mean by how flawed the system is and some suggestions to improve it.


gist scope

Grants write access to gists.

Let's say you want to build an app like GistBox to organize gists. In order to read read private gists you would need to request the gist scope.

Here's what users would see:

gist

Even if you don't want to create any gists, you still need to request write access. Some users may find that ok, but other users can be afraid of having someone creating or editing their precious code snippets.

Solution: what if we had read_public:gist, read_private:gist, write_public:gist, and write_private:gist instead?


public_repo scope

Grants read/write access to code, commit statuses, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories.

Another example: let's say you want to create an app like Waffle, HuBoard, or ZenHub to manage your issues. In order to have a basic functionality like creating issues on public repositories, you would need to request the public_repo scope.

Here's what users would see:

public repo

Note how broad this permission is. These apps have no interest on wikis, deploy keys, webhooks, or anything like that. But still, that's the only way to go.

Solution: what if we had read_public:repo_code, read_public:repo_issues, and write_public:repo_stars instead?


repo scope

Grants read/write access to code, commit statuses, collaborators, and deployment statuses for public and private repositories and organizations.

Finally, the issue I'm personally facing right now. Let's say you want to build an app like DevSpace to read public and private events. For this we'd have to use the repo scope.

Here's what users would see:

private repo

This is probably the most shocking permission scope. Even though we don't want to write anything we'd still need to request a permission that can change code, issues, and many other important things from private repos.

Solution: what if we had read_public:events_repo, read_private:events_repo, read_public:events_org, and read_private:events_org instead?


You see, those are just few examples, there are many other apps facing the same issue:


@syropian, @ashumz, @acroca, @drusellers, @burtonjc, @pierrebeugnot, @rauhryan, @homeyer, @sxgao3001, @marydavis, @nparsons08, @zhangchiqing, @wbeard, @jamie, @diophore, @glenngillen, @troy, @winston do you agree?


I love GitHub and I hope this discussion contributes back to their product. There's a lot of potential on this community and I believe we can make a change.

@maracaipe

This comment has been minimized.

Copy link

maracaipe commented Feb 11, 2016

+1

2 similar comments
@noscript

This comment has been minimized.

Copy link

noscript commented Feb 11, 2016

+1

@fdaciuk

This comment has been minimized.

Copy link

fdaciuk commented Feb 11, 2016

+1

@glenngillen

This comment has been minimized.

Copy link

glenngillen commented Feb 11, 2016

Yes, but I also need to expand on the scope of the issue.

I've been doing some consulting and advisory work lately. Some of it quite technical in nature which means people have been asking me to dig through private repos for them. The first time I got added to an organization that I wasn't managing myself I realized I'd also burdened that organization with all historical decisions I'd made to allow a 3rd party to "read and write to all public and private repositories". Which is surprisingly common. At the very least it seems every CI and code coverage tool requires it.

I removed the ones I didn't need any more, and informed the client (Client A) that CodeClimate would now have access to their repo. They were OK with it. Then new client and new tools. They were using CircleCI which uses GitHub for oauth and (understandably) requires "repo" permissions. Even though I'm not personally using CircleCI they now have access to all of "my" repositories too.

Next client (Client B) uses CodeCov.io. Same problem. Except now I'm not just granting them access to my repositories they also get access to Client A too. This quickly became untenable. The cumulative and transitive nature of these permissions across not just repositories but multiple clients was at best irresponsible on my part.

And so I'm left with either managing multiple GitHub accounts to work around it (which is a major PITA) or not being able to use anything that asks for permission to access private repos.

A massive 👍^(n*clients) from me.

@iPaulPro

This comment has been minimized.

Copy link

iPaulPro commented Feb 11, 2016

+1 Can't consider using DevSpace (and many other services) until this happens.

@jolaurin

This comment has been minimized.

Copy link

jolaurin commented Feb 11, 2016

+1

@luanmuniz

This comment has been minimized.

Copy link

luanmuniz commented Feb 11, 2016

👍 That's nothing more to add here, the idea and the concept kind of say everything.
I really hope Github stop and listen what the users have to say and start to make something about it

@pillowsoft

This comment has been minimized.

Copy link

pillowsoft commented Feb 11, 2016

+1

@acroca

This comment has been minimized.

Copy link

acroca commented Feb 11, 2016

I doubt anyone (other than GH because they have to implement it) will disagree with adding more granular permissions, it's always good to have more fine control.
So +1!

@troy

This comment has been minimized.

Copy link

troy commented Feb 11, 2016

Rather than another "+1" comment, which I don't think is useful, I'd change this request: how about a description of the current barriers to implementing this?

GitHub knows there's demand for this and I have no doubt, abstractly would like to see it exist just as much as everyone on this thread. That's never been a question. It seems much more likely that the implementation is actually much harder than someone who doesn't know GitHub's codebase would suspect, like perhaps because GitHub stores all repo-related assets (issues, etc) together and doesn't have a way to enforce fine-grained permissions via some access methods.

I'm more interested in learning more about the challenges we might not be aware of than about assuming either (a) GitHub is unaware that this would be useful, or (b) GitHub needs ideas how to codify permissions. While I certainly could be wrong, I doubt either of those is the case.

So, even as the person who may have first requested this from GitHub (December 8, 2011), I'm more interested in learning about implementation limitations that I might not be considering than I am in assuming I'm fully informed. I'd like to hear from GitHub more about what makes this particularly challenging to implement, though.

GitHub has done a great job with org-level restrictions on third-party applications and a way for org members to request approval from org admins.

One of my emails in a 2011 exchange with GitHub is below. The gist is that sooner or later, a third-party service with a lot of keys will get hacked. While that can't be prevented, the damage can be mitigated with fine-grained permissions so that only the few services which need code access (like CI) have it, restrictions and alerts on concurrent access with keys granted to the same developer ID, a developer-facing "Expire all granted keys" button, and perhaps the ability for integrations to flag a specific user/key as a honeytoken.

In case it helps any other OAuth key holders, here's the implementation (now using attr_encryptor) that my service uses to encrypt keys from GitHub and other services. Doesn't cover anywhere near all types of breaches, but does cover some. It's described in Taco's privacy policy.

One other reason: assuming the API is successful, third-party services will have meaningful numbers of OAuth tokens - that's the whole point. I could see a worst-case scenario where they get hacked (and maybe even don't notice), the tokens get used and source code gets out, and by the time anyone's aware of it, the story is "GitHub got hacked!&$@"

Even though you guys had nothing to do with it, it would make people rethink hosted source code hosting.

A token with repo scope is the keys to the kingdom, and making this level of access be the only way to get private repos is asking for people to accumulate more trust than they need. I'd argue that consumers should be pushed towards the metadata-only scope that doesn't currently exist, and the repo scope should be the exception, replete with big red "This app will have easy, complete access to your source code" warning letters on the grant page.

@Electryc

This comment has been minimized.

Copy link

Electryc commented Feb 11, 2016

+1

1 similar comment
@zhangchiqing

This comment has been minimized.

Copy link

zhangchiqing commented Feb 11, 2016

+1

@troy

This comment has been minimized.

Copy link

troy commented Feb 11, 2016

Instead of just adding "+1," how about adding information about your situation/environment or explaining your own opinion? There's no point in more +1's.

@dmethvin

This comment has been minimized.

Copy link

dmethvin commented Feb 11, 2016

...and in fact just highlights the flaws of the issues system that we would love to fix. Those of you who +1 this, each time you do that GitHub dutifully sends out a notification to those watching this repo, currently 108 people. Is your +1 worth interrupting the day of 108 people?

That's a rhetorical question, I'm unsubscribing from this thread because the important points have been made.

@luanmuniz

This comment has been minimized.

Copy link

luanmuniz commented Feb 12, 2016

@troy There is no point in "explaining your own opinion". About the situation/environment from Github and their codebase, speculate about their codebase is the worse thing we can do, because we know absolutely nothing and everything we think will be just speculation and will probably not apply to the the situation. We will maybe discard a few situations without even know whats actually happening.

Github is the one that need to come with their situation and opinion, as far as our knowledge goes, the only thing we can do, is work on a spec (high high level spec, pretty much like @zenorocha did in this post) and wait for them to give us some light. Anything more than that is effort on something we cant do anything or know nothing about, Sadly.

@dmethvin The "+1" comments make clear that this is not something that just 4 or 5 guys want. There is not many ways to "just agree" with things in Github and this is how much and many people care about the specific post/subject. Its important to make clear who cares about the subject. Until Github make another feedback system besides comments, this is what we have to express our support. By the way, this is one of the central points of this repository, another feedback system. Its on the README of this repo.

@miketaylr

This comment has been minimized.

Copy link

miketaylr commented Feb 12, 2016

I work an an app (https://webcompat.com) that is basically a UI on top of a github issues repo. In order to file a bug on someone's behalf I have to ask for public_repo. More than once people have said that's asking for wayyyyy too much (and I agree).

I would love an oauth scope like that allowed me to create issues for a public repo and nothing more.

edit: I have emailed support and asked for this twice, I believe.

@nazar-pc

This comment has been minimized.

Copy link

nazar-pc commented Feb 12, 2016

Definitely the reason I refused to use many third-party apps as soon as I saw permissions it wants to get.
Huge 👍

@martinjms

This comment has been minimized.

Copy link

martinjms commented Feb 12, 2016

+1

@zenorocha

This comment has been minimized.

Copy link
Contributor Author

zenorocha commented Feb 13, 2016

Me too @miketaylr. Here's the answer it received:

Hi Zeno,

No, not currently -- if you want to read events from a private repository, you need repo scope for now. Adding more granular scopes is on the team's radar, but I can't promise when it will happen.

I hope this answers your question, but let me know if there's anything else.

@rozzzly

This comment has been minimized.

Copy link

rozzzly commented Feb 13, 2016

+1

@migurski

This comment has been minimized.

Copy link

migurski commented Feb 24, 2016

+1, this has been a serious oversight on Github’s part for many years. At minimum, read-only repo scope should be a possibility. Organization and time granularity would be nice as well.

@paulmolluzzo paulmolluzzo referenced this issue Feb 25, 2016

Closed

Improve upvote / downvote comment handling #39

2 of 2 tasks complete
@soderlind

This comment has been minimized.

Copy link

soderlind commented Mar 16, 2016

+1

1 similar comment
@ryuheechul

This comment has been minimized.

Copy link

ryuheechul commented Mar 17, 2016

+1

@derhuerst

This comment has been minimized.

Copy link

derhuerst commented Mar 17, 2016

@soderlind @pranaypatel512 @ryuheechul

As there is a reaction feature on GitHub now, please don't post just "+1" anymore.

@ryuheechul

This comment has been minimized.

Copy link

ryuheechul commented Mar 20, 2016

@derhuerst got it.

@mezis

This comment has been minimized.

Copy link

mezis commented May 30, 2016

In case it helps anyone here save some typing, here's some boilerplate to show in your app.

You're about to sign in to APP for the first time.

We use Github's OAuth authentication mechanism both as a simple method to sign in, and to obtain an API token we can use to collect your statistics and display them to you.

Unfortunately, Github's permissions have very poor granularity: the only way for us to be able to count your comments and pull requests is to also to have full write access to your repositories! Of course, we'd never do that.

This is a known problem and Github is aware of it.

We take your privacy very seriously. If access permissions are a problem for you, feel free to ask us about how we protect your data.

Dear Github, surely having this type of copy all around isn't great press? The issue has been around and fed back for several years now...

@seannybgoode

This comment has been minimized.

Copy link

seannybgoode commented Feb 1, 2018

@dentarg - I think you're reading the documentation incorrectly. The scope specified is the same for source access and issues access:

image

@dentarg

This comment has been minimized.

Copy link

dentarg commented Feb 1, 2018

@seannybgoode No, there are two different systems, "GitHub Apps" (new) and "OAuth Apps" (old)

Read the text above that table

Unlike OAuth apps, GitHub Apps have targeted permissions that allow them to request access only to what they need. For example, a Continuous Integration (CI) GitHub App can request read access to repository content and write access to the status API. Another GitHub App can have no read or write access to code but still have the ability to manage issues, labels, and milestones. OAuth Apps can't use granular permissions.

@quicklywilliam

This comment has been minimized.

Copy link

quicklywilliam commented Feb 1, 2018

So, it sounds like 3rd party GitHub Apps can request Issues Only access but there is no way to do it from the built in Issues tracker?

@snarfed

This comment has been minimized.

Copy link

snarfed commented Feb 13, 2018

this, from https://developer.github.com/apps/getting-started-with-building-apps/#which-type-of-integration-should-i-build , is helpful for understanding how github themselves see the options.

TLDR seems to be, if you want granular permissions, make a GitHub App instead of an OAuth app.

@snarfed

This comment has been minimized.

Copy link

snarfed commented Feb 13, 2018

...except the catch is, GitHub Apps can't acquire OAuth scopes:

Note: You don't need to provide scopes in your authorization request. Unlike traditional OAuth, the authorization token is limited to the permissions associated with your GitHub App and those of the user.

so a GitHub app can act as a user to do some things, but not other things that require specific OAuth scopes, e.g. fetch notifications or follow other users.

@seannybgoode

This comment has been minimized.

Copy link

seannybgoode commented Feb 14, 2018

@dentarg - ah I see, thanks for clarifying

@ianforsyth

This comment has been minimized.

Copy link

ianforsyth commented Feb 24, 2018

+1

htuch added a commit to htuch/envoy that referenced this issue Mar 26, 2018

[RFC] Script for automating cleanup PR creation for deprecated featur…
…es at a given version

Usage:

tools/deprecate_version.py <deprecate for version> <deprecate by version>

e.g

tools/deprecate_version.py 1.6.0 1.7.0

A GitHub access token must be set in GH_ACCESS_TOKEN. To create one, go to
Settings -> Developer settings -> Personal access tokens in GitHub and create
a token with public_repo scope. Keep this safe, it's broader than it needs to
be thanks to GH permission model
(dear-github/dear-github#113).

Known issues:
- Minor fixup PRs (e.g. fixing a typo) will result in the creation of spurious
  issues.
- Using git blame can possibly miss issues.
- Need to do a better job at error handling when a user isn't in envoyproxy org.

TODO(htuch): This is just a proof-of-concept, if we think this is worth
pursuing, will cleanup style, comments, docstrings, error handling, etc.

Signed-off-by: Harvey Tuch <htuch@google.com>

htuch added a commit to envoyproxy/envoy that referenced this issue Apr 13, 2018

Script for automating cleanup issue creation for deprecated featur… (#…
…2905)

Usage:

tools/deprecate_version.py <deprecate for version> <deprecate by version>

e.g

tools/deprecate_version.py 1.6.0 1.7.0

A GitHub access token must be set in GH_ACCESS_TOKEN. To create one, go to
Settings -> Developer settings -> Personal access tokens in GitHub and create
a token with public_repo scope. Keep this safe, it's broader than it needs to
be thanks to GH permission model
(dear-github/dear-github#113).

Signed-off-by: Harvey Tuch <htuch@google.com>
@wtarreau

This comment has been minimized.

Copy link

wtarreau commented Apr 24, 2018

Well, I would personally like to have the ability to use a higher level to create an issue than to update them. The rationale behind this is that for opensource projects, it's very common to see people seek help by opening issues, resulting in 99% of issues being wrong, thus adding a significant burden. Because of this we simply cannot use Issues as an issue tracker and had to disable it, which is sad as it seems to fit the purpose well. At the very least I'd like to have the ability for collaborators only to create issues, and let anyone edit them. Then I could add many trusted project participants as collaborators to create new issues, and anyone (including the reporter) could update with more info as needed. I am very surprised that it is not possible yet given the burden it currently causes.

@VictorDenisov

This comment has been minimized.

Copy link

VictorDenisov commented Apr 25, 2018

👍 We need more fine grained access controls. The permissions are way to broad.

@rob3c

This comment has been minimized.

Copy link

rob3c commented May 17, 2018

apologies in advance for this workaround to yet another github limitation:
isaacs/github#283

@BarbzYHOOL

This comment has been minimized.

Copy link

BarbzYHOOL commented May 24, 2018

We need this

@FrederickGeek8

This comment has been minimized.

Copy link

FrederickGeek8 commented May 30, 2018

I would really like it if we could differentiate (at least on Github) between push (write) access and merging pull requests access to a repository. In managing an organization, I would love it if I could give collaborators/members the ability to merge pull requests themselves but not allow directly pushing to the repo. Even though a collaborator could immediately create and merge a pull request, they would at least be warned if the CI builds didn't finish or altogether failed. If a collaborator did leave the pull request open for a little while, it could lead to further discussion on the changes (if merited).

At the moment, I set up guidelines for my collaborators on when is appropriate to directly push to the repository as compared to submitting a pull request, however, it would be nice if there was some way to manually enforce this, at least on a Team level. I'm not sure if all of this would be a useful feature, but I personally feel like its very hard to find collaborators who I trust enough to hand the keys of the repository to.

@dentarg

This comment has been minimized.

@aspiers

This comment has been minimized.

Copy link

aspiers commented Jun 14, 2018

See also OAuth scopes by repository (or organization) · Issue #731 · isaacs/github.

(And BTW whilst I'm here, I should mention that IMHO this issue should not be discussed under the dear-github organisation because the isaacs/github issue tracker is a more appropriate location.)

@spaceneenja

This comment has been minimized.

Copy link

spaceneenja commented Aug 24, 2018

Not feeling comfortable extending github using third party apps is really quite annoying.

https://guide.unito.io/hc/en-us/articles/219394048-Which-GitHub-APIs-are-used-

@zumbuschms

This comment has been minimized.

Copy link

zumbuschms commented Dec 10, 2018

I stumbled over the very simple permission levels today. I have set up a Jenkins master to handle build and deployment of a new project. For the test environment I used my own account for our Github Enterprise instance, for the live environment I switched to our build user that has just read permissions to the repositories. With this setup the Jenkins pipeline is not able to set commit statuses. Therefore write permissions to the repository is required which is way to much for a build user. Having finer grained or custom permission levels would be great.

@dentarg

This comment has been minimized.

Copy link

dentarg commented Dec 10, 2018

@zumbuschms It looks like it is possible to grant write access to commit statuses with GitHub Apps.

See https://developer.github.com/apps/differences-between-apps/#requesting-permission-levels-for-resources

@blockjon

This comment has been minimized.

Copy link

blockjon commented Feb 19, 2019

I need a permission that would allow me to just list the names of someone's private repos. Maybe a scope called repo:list. I don't need to see their source code and I certainly do not need to be allowed to modify their source code. However, the only option I have is repo which would allow me to both read and write in their private repos which nobody in their right mind would allow a 3rd party.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.