Hacker News Reader

Comment by rileytg | Hacker News Reader

Looks really nice but you guys ask for too many permissions! SSH keys?? http://cl.ly/U1pP

Hey,

I've answered this numerous times in this thread, but I'll say it again, very loudly and very definitively: WE DO NOT WRITE TO YOUR SSH KEYS, EVER. EVER. EVER. We don't even read them.

Unfortunately, as beautiful as GitHub's API is, they've got their scopes for permissions completely wrong and we know they are working to fix this.

Short answer: https://gitter.zendesk.com/hc/en-us/articles/200178961-Why-d...

Long answer: https://gitter.zendesk.com/hc/en-us/articles/200176672-Authe...

Mike

I don't want to sound like a parrot here, but I'm VERY excited about the feature set of your product but I'm not going to try it with the current permissions model.

Do you have any communication channel into Github through which you can let them know that their permissions model stands to kill your business?

Yeah we've been talking to them. We've had nearly 10,000 people sign up, given we only launched very recently, I wouldn't say this is killing our business at the moment and we're confident they will deliver a solution in the future.

It would be exceptionally difficult for us to add/delete an SSH key by a bug, because we don't ever call or reference keys anywhere and there's really not much else we do other than GET items.

I see your explanation in https://gitter.im/login/explain and it suggests a business solution that doesn't require me to believe the promises of someone I don't yet trust.

"In order to create a good first-time user experience that allows people to create and join chat rooms for public repositories and organisations... [the rest of the technical explanation]".

Stop doing this.

Make this feature optional. I don't even want a public chat room for my company's private repo.

It has nothing to do with your company's private repo, it has to do with getting a list of ORGS you belong to.

In fact chats for private repos is a completely separate matter and we allow users to upgrade their access to GitHub's repo scope if they want access to private repos.

Otherwise we'd have to do: * signup (only public repos) * upgrade permissions -> org chats * upgrade permissions -> repo chats

And so then users need to understand three levels of permissions and scope and I don't want to burden people with that level of cognitive overload. It's hard enough to explain to people that they need to elevate privileges to get private repo access.

Whilst a few people share your view, we've had nearly 10,000 grant us this access in a very short space of time and so it's not massively affecting our product right now and we have confidence in the future that GitHub will change their permissions and introduce a read-only permission that we will then switch to.

I don't doubt your sincerity. Unfortunately, all of us have bugs, and if that bug in one step from write access to repos -- that is unacceptable.

I hope that Github is reactive enough to get permissions setup in a failsafe manner so I can give this a spin.

Reply on news.ycombinator.com