"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 ;))
Comments
"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