5 ms·

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 sc

by jorde 12y ago

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)

jgeewax 12y ago
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.
- malandrew 12y ago
  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?
  - garblegarble 12y ago
    http://en.wikipedia.org/wiki/XACML 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)
- Wingman4l7 12y ago
  It definitely isn't that coarse: https://developer.github.com/v3/oauth/#scopes https://developer.github.com/v3/oauth/#scopes
  - VoxPelli 12y ago
    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-changes-coming/ https://developer.github.com/changes/2013-10-04-oauth-change...
- hk__2 12y ago
  No it’s not, you can make an app that have access only to your public info, and/or public repos, etc.
- stanzheng 12y ago
  I agree that breakdown should be more anonymized. Readme permission/gitignore/license/code should have different end permissions
tommoor 12y ago
Yep, I'd love to try it but no way I'm authorizing access to every repo :(
- Karunamon 12y ago
  How exactly is an editor for stuff on your repos supposed to do its job otherwise?
  - matt_ 12y ago
    He said he wouldn't do it for 'every' repo. It would be different if the permissions were on a per-repo basis.
    - Karunamon 12y ago
      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.
      - edwintorok 12y ago
        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.
      - tommoor 12y ago
        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?
lalos 12y ago
Here are some screenshots: explore: https://dl.dropboxusercontent.com/u/52991/prose.io/explore.png https://dl.dropboxusercontent.com/u/52991/prose.io/explore.p... switch branch: https://dl.dropboxusercontent.com/u/52991/prose.io/switch_branch.png 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 https://dl.dropboxusercontent.com/u/52991/prose.io/edit.png
bmelton 12y ago
I don't know how a screenshot will prevent it from doing anything malicious, but the source code might: https://github.com/prose/prose https://github.com/prose/prose
- deleted 12y ago
  [deleted]
leorocky 12y ago
"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.
hrjet 12y ago
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.

by jorde 12y ago

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)

jgeewax 12y ago

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.

malandrew 12y ago
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?
- garblegarble 12y ago
  http://en.wikipedia.org/wiki/XACML 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)
Wingman4l7 12y ago
It definitely isn't that coarse: https://developer.github.com/v3/oauth/#scopes https://developer.github.com/v3/oauth/#scopes
- VoxPelli 12y ago
  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-changes-coming/ https://developer.github.com/changes/2013-10-04-oauth-change...
hk__2 12y ago
No it’s not, you can make an app that have access only to your public info, and/or public repos, etc.
stanzheng 12y ago
I agree that breakdown should be more anonymized. Readme permission/gitignore/license/code should have different end permissions

tommoor 12y ago

Yep, I'd love to try it but no way I'm authorizing access to every repo :(

Karunamon 12y ago
How exactly is an editor for stuff on your repos supposed to do its job otherwise?
- matt_ 12y ago
  He said he wouldn't do it for 'every' repo. It would be different if the permissions were on a per-repo basis.
  - Karunamon 12y ago
    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.
    - edwintorok 12y ago
      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.
    - tommoor 12y ago
      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?

lalos 12y ago

Here are some screenshots: explore: https://dl.dropboxusercontent.com/u/52991/prose.io/explore.png https://dl.dropboxusercontent.com/u/52991/prose.io/explore.p... switch branch: https://dl.dropboxusercontent.com/u/52991/prose.io/switch_branch.png 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 https://dl.dropboxusercontent.com/u/52991/prose.io/edit.png

bmelton 12y ago

I don't know how a screenshot will prevent it from doing anything malicious, but the source code might: https://github.com/prose/prose https://github.com/prose/prose

deleted 12y ago
[deleted]

leorocky 12y ago

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

hrjet 12y ago

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.