GitHub Has a Permission Problem • Hacker News Board

Re: GitHub Has a Permission Problem

#81

Post by voltagex_ » Wed, Mar 17, 2021, 4:30 AM UTC

cortesoft wrote: post #67

vosper wrote: post #55

Earlier quoted context omitted.

> The system works not by making it hard to steal money, but by making it easy to get back. In other countries the system works by making it hard to steal money: I'm in New Zealand, and you can't do really anything with my account number, except pay me. Direct debit does exist, but it's a lot harder to setup (I have to send the bank original signed documents if I want to setup a direct debit from my account) to the p…

Right, and that is why I kinda prefer the American system.... it is very easy to use and set up direct deposit and direct payments, and most of the time nothing bad happens. The few times something bad happens, it is fixed. I'd rather take the occasional having to wait a few days to sort out a fraud charge than have to be inconvenienced every time I want to send or receive money.

In Australia, I can send money to just about any other Australian with a bank account using an email address or phone number - and it's mostly instant. The fallback is an account number and it'll take a couple of days to go through. There's no charge for this.

Re: GitHub Has a Permission Problem

#82

Post by ncallaway » Wed, Mar 17, 2021, 4:32 AM UTC

thayne wrote: post #75

ncallaway wrote: post #62

Earlier quoted context omitted.

It's not, though. The legal system, and your bank will protect you in this scenario. You would report the fraud, and you would get your money back. In the case of plaid almost every bank has somewhere in their terms of service that you are responsible for protecting your online banking password, and they are not liable if you have a loss as a result of a third party getting your password from you. Which means if Plai…

It could still be a lot better though. For example, there could be an oauth-like flow where you confirm to your bank that you authorize paying the merchant the amount listed. It seems like banks would be motivated to have something like that since it would reduce the chances of them having to pay out for fraud.

Oh, yea, no doubt that the payment side could also be a lot better. No arguments here.

My only point is that on the payment side, the technology doesn't provide any security, but the legal framework does. But from the password management side, you're in a technology danger-zone for security, and the legal framework says "caveat emptor", so I think that one is the "worse" problem of the too.

But, I agree, the payment side should be improved

Re: GitHub Has a Permission Problem

#83

Post by runarberg » Wed, Mar 17, 2021, 4:35 AM UTC

cortesoft wrote: post #67

vosper wrote: post #55

Earlier quoted context omitted.

> The system works not by making it hard to steal money, but by making it easy to get back. In other countries the system works by making it hard to steal money: I'm in New Zealand, and you can't do really anything with my account number, except pay me. Direct debit does exist, but it's a lot harder to setup (I have to send the bank original signed documents if I want to setup a direct debit from my account) to the p…

Right, and that is why I kinda prefer the American system.... it is very easy to use and set up direct deposit and direct payments, and most of the time nothing bad happens. The few times something bad happens, it is fixed. I'd rather take the occasional having to wait a few days to sort out a fraud charge than have to be inconvenienced every time I want to send or receive money.

In my experience it is really hard to deposit money into another persons account in America. In my home country in Europe, all I need is their account number and their personal id number and I can deposit straight from my online banking system. They don’t have to be in the same bank or nothing.

In America this is so much more complicated. I have a hard time depositing money to my partner outside of my credit union’s calling hours, even though we literally share each other’s accounts.

Re: GitHub Has a Permission Problem

#84

Post by [deleted] » Wed, Mar 17, 2021, 4:45 AM UTC

philsnow wrote: post #70

Yes GitHub has this problem, but it's not a GitHub problem, it's an oauth problem. Oauth is better than the previous state of the art (either app-specific passwords that can do anything you can do or else literally just your own username and password), but it has a huge UX problem around least privilege. In general it's very opaque what the requested permissions can be used to do. Some companies get this pretty right…

[deleted]

Re: GitHub Has a Permission Problem

#85

Post by sriku » Wed, Mar 17, 2021, 4:51 AM UTC

I'm.going to say the most wrong answer for this ...just because I think not enough people know about this possibility - Use fossil-scm!

You an run it on a cheap server and get collaboration, wiki, tickets all packed into a single sqlite file. The single fossil executable has the server in it.

Sadly, integrations for workflows are another story yet to be written.

Re: GitHub Has a Permission Problem

#86

Post by welder » Wed, Mar 17, 2021, 4:55 AM UTC

GitHub doesn't have the granularity for repo write permissions needed. For ex, if you only need read permission but you need to write a repo webhook once you're forced to ask for full repo write permissions. I've emailed GH support multiple times about that.

Re: GitHub Has a Permission Problem

#87

Post by fedorareis » Wed, Mar 17, 2021, 5:05 AM UTC

paxys wrote: post #40

Github does have repo-specific permission grants. The app in question is probably not using it, but it is possible. Here's what that consent screen looks like - https://docs.github.com/assets/images/install_permissions.pn... . You do NOT have to give access to your entire account/organization to a well-built app.

Thank you for posting that image. I was was pretty sure I remember giving repo specific permissions to apps but reading the post and all the comments made me think I wasn’t remembering correctly.

Re: GitHub Has a Permission Problem

#88

Post by evanelias » Wed, Mar 17, 2021, 5:32 AM UTC

colinchartier wrote: post #23

My YC company is a GitHub app [1] and the "act on your behalf" thing is just a really poorly written message for the new (github apps vs oauth apps) apps interface. There's even a hilarious thread on the github forum itself about "act on your behalf" when all it requests is your email and avatar [2] Ironically the newer apps system does have fine grained permissions, but seems more intrusive because of the strange wo…

Totally agree. I really wish GitHub would revise all of their permission wording. Several of these are unnecessarily scary or just plain weird, such as "Read access to emails" to refer to ability of an app to see your email address.

Re: GitHub Has a Permission Problem

#89

Post by spockz » Wed, Mar 17, 2021, 5:33 AM UTC

jez wrote: post #11

This is obviously a subject the author cares passionately about, because the article uses a lot of exclamation marks. But this tidbit struck me as hilariously out of touch: > Let's imagine your bank let you sign in to 3rd party services in a similar manner. How many people would click through on "Let ACME corp act on your behalf on your Citibank Account". I think most people would be super scared of permissions like…

This is why we have PSD2 in Europe. Additionally, there was a ruling somewhere that until a bank allows for a proper machine interface like an API, it must not actively block scrapping but the details on that are fuzzy atm.

Re: GitHub Has a Permission Problem

#90

Post by judge2020 » Wed, Mar 17, 2021, 5:39 AM UTC

jrochkind1 wrote: post #18

This has been bothering me for a while too. Without repo-specicific permissions at least , it sort of requires me to have separate github accounts for personal stuff, work stuff, contract stuff (per client) etc, doesn't it? Even if I'm willing to risk Some Serivce(tm) having write access to all my repos cause I want it for a personal project, I can't ethically give it access to work/client repos too. And yet, I must.…

The correct way is either you join their GH org (which is the best method in terms of IP ownership as well) or you create a GH org for each contract and set up apps with access to only relevant repos in that org.