4 ms·

"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 W

"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.

teacup50 12y ago
... And people wonder why we don't want to put our corporate code on a public cloud host.
- _mql 12y ago
  Hi! I'm the developer behind the original version of Prose: http://developmentseed.org/blog/2012/june/25/prose-a-content-editor-for-github/ 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 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 http://substance.io Cheers, Michael
namecast 12y ago
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 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.

teacup50 12y ago

... And people wonder why we don't want to put our corporate code on a public cloud host.

_mql 12y ago
Hi! I'm the developer behind the original version of Prose: http://developmentseed.org/blog/2012/june/25/prose-a-content-editor-for-github/ 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 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 http://substance.io Cheers, Michael

namecast 12y ago

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 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.