Could anyone provide screenshots? I hate to be a hater but authorizing an app to access all my private repos is little too much (not sure how GH allows OAuth scoping)
"This application will be able to read and write all public and private repo data. This includes the following:
Code
Issues
Pull requests
Wikis
Settings
Webhooks and services
Deploy keys
"
Indeed, no way am I authorizing this. Why does it need deploy keys and settings access. That's insane. I can't even do that because that would give it access to my job's code too, although I should probably create a new, separate GitHub account for my job. One time I said yes to one of these, tenexer I think it was, and the thing added webhooks to all hundred some private repos for my job. I ended up having to create a script to remove all those hooks. I could have been fired for that I bet.
There just isn't much granularity there - GitHub OAuth enabled integrations that need repository access can jump from having no specified scope - which grants access to your profile data only - to scope 'public_repo', which grants read-write access to all the data you've listed above, in any public repository, and then to scope 'repo', which grants the same for public and private repos.
It's a shame, because most GitHub integrations I've seen seem to need enough access to just list your repositories (public and private) and ask your permission to enable a webhook on a given repo at your request.
There's no way to do that with GitHub OAuth at the moment without asking for the 'repo' scope, and along with it a whole load of privileges that most people just can't / won't feel comfortable granting.
I'm no longer involved in the development. However, I do understand your security concerns. But I think this is not just a discussion about the limitations of OAuth Scopes. When using a hosted service, you always pay the price of loosing full control of your data. In return it's very convenient.
I wrote an article about decentralized publishing the other day.
I would also like to mention the project I'm working on right now, Substance. It is an easy-to use self-publishing system, which runs locally and thus gives you full control about your content. (at least until you publish it, because then there's no way back ;))
GitHub are also working on enabling users to accept just a subset of the requested scopes, like just access to public repos, which will make using all of the more fine-grained scopes easier: https://developer.github.com/changes/2013-10-04-oauth-change...
http://en.wikipedia.org/wiki/XACML would be one - it can be a little complicated, but if you can get over that it's quite nice and also adds the idea of an Obligation (something that must be performed on a grant/deny - for example, logging/e-mailing)
Sounds like a UX nightmare and a huge pain. I'm glad that privacy maximalists don't design user interfaces...
Wow, this comment sounds a lot more dickish than it was intended to. What I mean is, secure design would be that the app can't even see repos that it isn't authorized for, which means the user has to go through some back channel privacy settings page to authorize it every time they set up a new repo.
I don't want to have to specifically authorize x y and z repos every time I touch the app, and I seriously doubt anyone else does either.
Actually we do design UI, every day. And there are plenty of ways to do this in a comfortable fashion without authorizing read access to the contents of every repository. You could for example, show a list of all repos and when you click to edit one for the first time ask for permissions once for that repository - hardly a UX nightmare?
You probably don't want some random, just-released / potentially buggy application touching all your repos. Wouldn't you want to test it on a throwaway repository first to see if you actually want to use the app / does the app work properly, and then authorize it only for the repos you want.
Comments
Could anyone provide screenshots? I hate to be a hater but authorizing an app to access all my private repos is little too much (not sure how GH allows OAuth scoping)
"This application will be able to read and write all public and private repo data. This includes the following:
Code
Issues
Pull requests
Wikis
Settings
Webhooks and services
Deploy keys "
Indeed, no way am I authorizing this. Why does it need deploy keys and settings access. That's insane. I can't even do that because that would give it access to my job's code too, although I should probably create a new, separate GitHub account for my job. One time I said yes to one of these, tenexer I think it was, and the thing added webhooks to all hundred some private repos for my job. I ended up having to create a script to remove all those hooks. I could have been fired for that I bet.
This has more to do with the GitHub API and the way that they manage scopes than anything else:
https://developer.github.com/v3/oauth/#scopes
There just isn't much granularity there - GitHub OAuth enabled integrations that need repository access can jump from having no specified scope - which grants access to your profile data only - to scope 'public_repo', which grants read-write access to all the data you've listed above, in any public repository, and then to scope 'repo', which grants the same for public and private repos.
It's a shame, because most GitHub integrations I've seen seem to need enough access to just list your repositories (public and private) and ask your permission to enable a webhook on a given repo at your request.
There's no way to do that with GitHub OAuth at the moment without asking for the 'repo' scope, and along with it a whole load of privileges that most people just can't / won't feel comfortable granting.
... And people wonder why we don't want to put our corporate code on a public cloud host.
Hi! I'm the developer behind the original version of Prose:
http://developmentseed.org/blog/2012/june/25/prose-a-content...
I'm no longer involved in the development. However, I do understand your security concerns. But I think this is not just a discussion about the limitations of OAuth Scopes. When using a hosted service, you always pay the price of loosing full control of your data. In return it's very convenient.
I wrote an article about decentralized publishing the other day.
https://medium.com/p/626055376c81
I would also like to mention the project I'm working on right now, Substance. It is an easy-to use self-publishing system, which runs locally and thus gives you full control about your content. (at least until you publish it, because then there's no way back ;))
See: http://substance.io
Cheers, Michael
Here are some screenshots: explore: https://dl.dropboxusercontent.com/u/52991/prose.io/explore.p...
switch branch: https://dl.dropboxusercontent.com/u/52991/prose.io/switch_br...
edit file (pretty useful for READMEs): https://dl.dropboxusercontent.com/u/52991/prose.io/edit.png
Couldn't agree more... Do we really need to grant read and write access to all repos? Sucks if GH's scoping is that coarse.
It definitely isn't that coarse: https://developer.github.com/v3/oauth/#scopes
GitHub are also working on enabling users to accept just a subset of the requested scopes, like just access to public repos, which will make using all of the more fine-grained scopes easier: https://developer.github.com/changes/2013-10-04-oauth-change...
No it’s not, you can make an app that have access only to your public info, and/or public repos, etc.
Unfortunately Amazon is the only cloud provider out there with a robust ACL system.
Is there an open industry standard for implementing ACL policies flexibly like the one Amazon has?
http://en.wikipedia.org/wiki/XACML would be one - it can be a little complicated, but if you can get over that it's quite nice and also adds the idea of an Obligation (something that must be performed on a grant/deny - for example, logging/e-mailing)
I agree that breakdown should be more anonymized. Readme permission/gitignore/license/code should have different end permissions
Yep, I'd love to try it but no way I'm authorizing access to every repo :(
How exactly is an editor for stuff on your repos supposed to do its job otherwise?
He said he wouldn't do it for 'every' repo. It would be different if the permissions were on a per-repo basis.
Sounds like a UX nightmare and a huge pain. I'm glad that privacy maximalists don't design user interfaces...
Wow, this comment sounds a lot more dickish than it was intended to. What I mean is, secure design would be that the app can't even see repos that it isn't authorized for, which means the user has to go through some back channel privacy settings page to authorize it every time they set up a new repo.
I don't want to have to specifically authorize x y and z repos every time I touch the app, and I seriously doubt anyone else does either.
Actually we do design UI, every day. And there are plenty of ways to do this in a comfortable fashion without authorizing read access to the contents of every repository. You could for example, show a list of all repos and when you click to edit one for the first time ask for permissions once for that repository - hardly a UX nightmare?
You probably don't want some random, just-released / potentially buggy application touching all your repos. Wouldn't you want to test it on a throwaway repository first to see if you actually want to use the app / does the app work properly, and then authorize it only for the repos you want.
every is the key word here.
I don't know how a screenshot will prevent it from doing anything malicious, but the source code might:
https://github.com/prose/prose
Similarly, most of the CI tools require huge number of permissions, including Travis.
GH has OAuth scoping, but it needs to be more fine-grained. Say, configurable to per-repository level.