GitHub Has a Permission Problem | Hacker News Reader

GitHub Has a Permission Problem

games.greggman.com

264 pointsphreack120 comments

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 that. Instead they'd want very specific permission like, only permission to deposit money, or only permission to read the balance, or only permission to read transactions, etc...

It is so, so much worse than that. Most banks don’t even provide OAuth APIs, so to hack around this third parties just straight up ask for your bank username and bank password so that they can turn around and log into that site and scrape the HTML UIs that come back from logging in.

“I think most people would be super scared of that.” No doubt these people exist (hello!) but like, there’s a whole industry built around this.[1] Possibly the banking example is not the best piece of supporting evidence for the article’s claim.

[1] https://plaid.com/

I came to the comments as soon as I read that part. It's funny they probably don't realize that's what FI aggregation at their bank is doing. Screen scraping is a necessary evil until we can get banks in America with APIs.

I remember this topic coming up at work and I said something along the lines of why would anyone provide their online bank account credentials to another service in order for them to verify your account and other members of my team (all software developers and operations) didn't see a problem with it.

It seems like there's a significant disconnect between what people believe is good security practice.

My wife: “I didn’t know it did that. Oh well”

Bad cyber security is almost but not quite like sleeping around behind your partners back. If you get burned you both suffer.

I don't know how this insanity still exists. Sharing login data with third parties is likely violation of bank ToS and might deprive you of fraud protection (bank might argue that you were grossly negligent by sharing credentials).

I guess acceptance of that crazy scheme is regional thing. Paypal tried to pull that over here but they backed out after a week of extensive backlash. And EU mandates that banks provide APIs in PSD2 directive.

I mean PayPal still right now today does it for the “verify your bank account” feature.

I don't think they do in Australia... how odd.

As far as I recall this article is accurate. They send two small amounts and ask you to type it in to confirm it came through.

https://www.paypal.com/au/smarthelp/article/how-do-i-confirm...

I recently needed to add a personal Chase account to a business Chase account to send a transfer.

I kid you not, their own account linking flow used Plaid to collect my Chase(!) personal credentials and verify my Chase(!!!) personal account, within their own web UI while actively signed into my account.

Granted, there is capability in that UI to link any external account, so you can sign into other banks. But I mean come on...at least implement something secure for your own damn accounts!

You can almost smell the internal bureaucracy and dysfunction.

This may be a case of an external account in practice. There are many banks running the retail and business accounts under a similar corp name, but in practice they're separate entities which don't share infrastructure or processes.

(I'd love to know the reason, I'm sure someone here knows the details)

There’s just very little way around it :/ if I want to transfer money between different banks or services it’s usually much faster by giving out your creds. Worse, if I want to do my taxes Turbotax simplifies that whole process tremendously if I give them creds for all my financial services... it’s pretty crazy how much trouble you must be willing to accept to avoid leaking your creds.

It’s the Uber/Airbnb model. Plaid does something totally unacceptable as a trade off for a good service. Eventually the bank APIs will catch up, Plaid will become secure, and they’ll have the dominant market position with a high cost of entry.

Looking at their FAQ, mwave seem to have ceased this practice but they had a thriving online business at the time I wrote this:

https://lolware.net/2016/11/17/requesting_bank_login.html

Everybody single person who provided feedback on this blog argued I was "being pedantic about nothing", "throwing your fedora at them", and even at American Express they took very seriously the "get your money back" angle but seemed confused as to why I didn't want to hand passwords out.

The actual money movement “API” is by far the scarier part of this. Any entity you’ve ever paid has your account number, and that’s all they need to pull more money. People talk about this like your online banking password is protecting your money... it’s not. If someone adds an online bill pay recipient from the web portal it triggers loud and slow verifications and confirmations. If someone submits an ACH transaction for my account number in their nightly batch, the money just flies right out.

> the money just flies right out.

And then flies right back in once you report the fraud. The system works not by making it hard to steal money, but by making it easy to get back.

This is like credit cards... yes, a shady store can steal money from you.... but then you get it back and they go to jail.

> 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 point that I think many people don't even use it.

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.

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

Bank of New Zealand online banking doesnt seem that inconvenient, or different, from the American system. add payee, enter amount, click pay then confirm.

https://www.bnz.co.nz/support/internet-banking/payments/addi...

Right, but my power bill, for example, is variable and I don’t want to have to manually pay it every month.

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.

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.

AFAIK, this is because criminals used to move money anonymously that way, and banks now have more of a legal responsibility to know where money is coming from.

Get yourself formally added as an authorized user of the account and you won’t have this problem anymore.

Or you setup something outside bank account numbers that accomplishes that? Here in Canada we have interact e-transfers via email or text. Have yet to meet someone who doesn’t have it setup and works great and doesn’t require a bank account - only time that comes up is for direct deposit from employers Goverment ect

We still have junk like PoLi [1] which asks you for your internet banking credentials, and government departments use this.

I'm looking at you, NZTA.

Can't wait for the PaymentsNZ [2] effort to be fully implemented and widely adopted, so I can finally use real APIs to access this data, with low privilege throwaway tokens.

[1] https://www.polipay.co.nz

[2] https://www.apicentre.paymentsnz.co.nz

Oh yeah, PoLi is indeed junk, and I've also been surprised to see NZ Govt departments using it. I refuse to use PoLi, and I'll do a bank transfer or pay the debit card processing fee (if it's not exorbitant) instead.

ACH fraud is not that simple to detect or revert. How soon would you know if $500 exited your checking account? If it's a small-business account, with most banks, you have 24 hours to report each debit that you want reversed. If it's a personal account, you may have up to a month. But the same merchant account can debit your account again, even while you are reversing their previous debits. You can't block them with a personal or basic small-business account, you have to upgrade to an account that you always keep $100K in.

The banks' suggestion? Close the account, open a new one, and never give anyone the account and routing numbers. Never write a check from that account. Use the bank's web site to initiate bill payments – they'll get checks from the bank's account.

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 Plaid is a bad actor, or if they lose your password on accident, and your money is taken, the bank will disclaim all liability, and will not be obligated to make you whole.

So, while it might be easier for money to flow out of your account due to ACH fraud, it'll be a lot harder to get that money to come back if it's due to your own password handling mistakes.

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.

Unauthenticated credit/debit transfers are a pretty uniquely American thing. Many other countries have bank transfers that require the customer to authorize it (either ahead of time, or synchronously during the transaction, as you describe) before the money moves.

And looks like author lives in Tokyo, not sure where is he from. The only time I pay with credit card and give power for others to pull automatically money from there is American companies. Otherwise I always do the wire or approve the é-bills manually.

> Many other countries have bank transfers that require the customer to authorize it (either ahead of time, or synchronously during the transaction, as you describe)

Only half-correct if you're talking about SEPA. Legally, the customer has to fill out a "SEPA direct debit mandate" - but the company initiating the direct debit transfer only has to keep it on file.

I have a business account at my bank, I can theoretically file a direct debit for as much money as I want against any SEPA-reachable bank account (in practice, most banks including mine limit that amount until you can prove, e.g. via presenting a bill, that this is a correct amount) - but if someone disputes it or, worse, files a legal complaint that causes police to investigate and I can't produce that mandate signed/authorized by the customer, I'm in extremely hot water.

What if you produce the mandate signed by someone impersonating the customer? I imagine that is the typical case for ACH fraud. Not everyone has their own ACH connection; you would plug in a stolen account number at some merchant.

To be honest I don't know who is held liable if you can prove you have had a valid mandate, never had to dive that deep into the rabbit hole that is SEPA - and I guess the specific rules depend on the country you're in. I assume though that similar to CC fraud, one or both banks involved eat the loss.

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

These things exist in other countries.

E.g. with e-Invoicing in Sweden, your electricity company, credit card company etc send the bill to your bank, it shows up as a PDF in your online banking, and you confirm or deny it there. If you want it to be auto-confirmed (e.g. utility bills), that's a setting on the bank end of things, not the utility end of things.

A similar thing exists in Norway. For auto-payments you have to register every agreement in the web portal of the bank*, and only after that can they withdraw money automatically. You can also set limits on how much they can withdraw per month, and if you suspect that something is fishy you can cancel the registration forcing them to send you an invoice electronically or on paper.

The dutch iDeal system works like that. The merchant redirects you to your banking website where you can authorize the transaction, which tends to involve some 2-factor rigamarole, after which point the bank redirects you back to the merchant.

A more recent innovation is banks exposing this more directly to consumers. I can create a "payment request" in my banking app which generates an iDeal url which I can send by email/text/facebook/whatsapp/qr code/carrier pidgeon to someone who can then pay me. No exchange of account numbers required and the amount paid is deposited in your account within seconds.

So yes, an oauth-like flow definitely is the way to go. It's more secure and more convenient, which is a pretty unusual combination.

> You would report the fraud, and you would get your money back.

There's a time limit on this, though, right? So if you're not checking your account every N days, you could still get screwed?

Yes. At least in Germany (but I believe it's the same for all SEPA transactions), it's eight weeks for the simplified return where you just tell your bank "get that money back, please" and it's pretty much instantly credited to your account. That applies regardless of the legal status of the transaction.

For non-authorized transactions, you have 13 months to recover the money. Since it will have cleared after eight weeks, the whole procedure takes considerably longer and most bank employees will not be too familiar with it.

I had recently experienced that when somebody used my bank account to sign up for Netflix. I only caught it after three months (I mostly blame my bank for not providing a "new ACH transactions" report). Netflix wasn't helpful (and apparently has no interest in stopping this, their fraud detection allowed for creating an account with the legal name "f f", a German bank account and a none-German IP) and my bank immediately reversed the last two transactions (still within eight weeks window). The first one took about three months, but I don't know who or what was responsible for the delay.

US ACH rules are 60 days for consumer accounts, and 3 for business accounts.

Interesting note: you can probably call your bank up and request that the disallow ACH withdrawals from your account if triggered by some third party.

You can still get ACH deposits. You can still use the bank's bill pay and they will send the payments over ACH (so you can push funds over ACH from the account). But someone else can't _pull_ funds over ACH from that account.

Certainly the banks I use have this as an option, and it's useful sometimes. As long as you remember and don't try to pull yourself from one of your other accounts, of course.

I, too, clicked through into the comments as soon as I read that bit, wondering whether someone else had the same reaction as me.

As a UK citizen who's lived in the states for the last 4 years, the permissions that Venmo and other financial apps require is even more horrifying than the rest of the US financial system ("tell us what tax you think that you owe, and if you're wrong, you go to prison" // "you have to build up credit in order to be able to afford anything - but if you ever fail to pay it off, you'll be in debt for the rest of your life").

It gets much worse. There are payment methods building upon this structure that fully analyze your bank account transaction history for income details to produce risk results and give back these raw results to merchants.

https://developers.paywithmybank.com/api/#get-user-income

It's even worse than the HTML scraping. Banks will do literally anything if the instructions arrive by fax or mail, assuming you get the account number correct. The practical security of banking is ridiculously bad.

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.

Banking is not secure. The bank industry is held together by strings of rules and regulations that, fortunately, very few people are willing to pull at.

Its funnier when you know that banks are actually planning on sharing data via something similar to Oauth. Its called Open Banking PSD2.

Even better, banks in may country are banding together to create identity provider for the web. So basically you will be able to use their super-secure login to online banking based on the state of the art SMS second factor and localhost port probing via the web browser (/s), to identify yourself on the web (up to AML level), sign contracts, or access government services.

https://bankovni-identita.cz/o-projektu/

Security of this project is anyone's guess. They certainly have a lot of flashy websites to lure people in, but actual documentation is behind a signup wall. Each bank will create its own independent IdP infrastructure, so this is gonna be a lot of fun for security researchers to be sure.

After this is done, it seems like I'll already be registered with 6 online IdPs (not all of these are banks) that will be able to identify me enough to allow online communication with the government services.

This proliferation of IdPs is getting quite scary...

Let's not let that be an excuse to settle for poor security, either from Github or our banks.

I agree the way Plaid/Yodlee/etc ask for passwords is insane. I've "closed the tab" several times when I hit that. Just the other day I got asked for my bank passwords for a mortgage refinance. I refused and they said I could send them bank statements instead.

On the other hand, if I want to access a customer's CI pipeline there's no one at Semaphore I can email to find a more-secure workaround. I have to grant access to my whole Github account. As a freelancer with a lot of clients, that's a big problem for me.

> Reading public info should not even be listed! It's already obvious that all your public info can be read by the app. That's the definition of public! There's no reason to tell me it might read it. It doesn't need permission to do so.

This is the permission you grant apps using GitHub for SSO, that allows GitHub to know what account you're logged in as. The information itself is public (anyone could scrape it from your public GitHub profile); but the fact that you are logged into that account is not public.

If any website could ask GitHub "is the current user logged into GitHub right now, and if so, as what account", without the user's consent, then that'd be considered a CSRF fingerprinting/permacookie vulnerability in GitHub.

In other words, the problem is with describing secret information as "public".

GitHub phrases the permission as something like “This app can view your public email address.”

The “public” there is GitHub distinguishing which of the email addresses associated with your account it is exposing to the app. One of a GitHub account’s email addresses can be set to be publicly shown on your GitHub profile. Other email addresses can also be associated with your account (for login/recovery), but these are private. The permission only allows the app access to the public one, not the private one.

Really, it’s not the “email address” in the grant description that would properly be qualified by “private.” It’s the “your.”

But granting the app permission to know the logged-in GitHub user’s numeric ID, isn’t part of any of the permission scopes, but is instead the base permission the app gets when you click “Accept” on the app binding request. The only thing the “view your email address” permission allows is for the app to look up the primary public email address (if one exists!) for the GitHub account with the ID it now already knows, given a successful OAuth callback.

Technically, just having the GitHub ID is enough to SSO you against GitHub, in the oldschool OpenID sense of SSO (or to track you across the internet.) The implicit default scope of an app grant already breached the privacy of “your.” So the additional permission about emails doesn’t have to qualify anything, because it’s not giving anything still private away. It’s just protecting something actually public from being mapped to from the private credential the app, at that point, already has access to. It’s putting up a roadblock in one direction of a lookup that could be done entirely without the API (by scraping user’s profile pages for internal user IDs + email addresses, and building a table indexed by user ID.)

And also a lot of info is publicly available on the website but you still need an API token to access it programmatically. You could scrape it, sure, but that is not officially supported.

On the other hand, I love that GitHub forces app developers to ask for so many permissions. Here is why…

When my teammates asked me to provide internationalization support for all our projects via Crowdin, I gave them a detailed list of all the permissions Crowdin’s app requires to sync data back and forth via the GitHub integration. The answer from the product manager, —No way! Build that yourself. We are not giving full access to all our public and private repositories to a third-party company to have translation capabilities.— As a result, I spend a couple of weeks writing a custom Gettext parser to allow my teammates to provide translations via PO files.

Similarly, when my teammates wanted to use a popular CI/CD service called Travis CI, I also gave them a list of all the permissions required to offer most, if not all, their features. Again, a product manager told me to stop and use something that we could self-host, so I went with GitLab CI.

I could continue telling stories, but the point is, thanks to GitHub’s extreme and ambiguous API permissions, I can continue working at a bit company and earn a lot of money. Other people probably spend five minutes integrating third-party services they blindly trust and then move on to more exciting work. But as my father used to say, work to live, not the contrary, so if I can get FAANG money by writing simple programs to replicate what a SaaS has to offer, I feel accomplished and can move on with my life.

Thank you, GitHub, for creating an app integration experience so bad that I can keep my job.

> How many people would click through on "Let ACME corp act on your behalf on your Citibank Account"

Banking is a terrible example because it's literally how it works. Try to link a bank account to PayPal or TransferWise, they'll ask you your username and password for your online account to that bank, and the next screen asks for the verification text you got as they literally log in as you. And ACH, the system your employer uses to direct deposit your salary also allows for withdrawals.

Hopefully security is better where the author is writing from...

> Try to link a bank account to PayPal or TransferWise, they'll ask you your username and password for your online account to that bank

I don't remember having to do that for paypal. I do remember them asking for the routing and account number and that they asked me to verify the cash amount of a deposit they made in order to confirm the account.

I went through a similar procedure when I added my bank account as an external account to my E-trade account. I never had to provide my online banking credentials (though it was an option, I opted to verify deposit amounts instead).

They use that Plaid thing to try to instant link and Plaid asks for your credentials! But fortunately Plaid crashes, throws errors all over the JS console and ultimately fails, leaving you with threes day verify vis ACH. Many Plaid failed because i blocked the trackers, which is another thing ...Plaid asks for U/P on page that's loading trackers - leaking my credentials maybe?

When I see Plaid on something, I'm Noping out of there

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. Or have a bunch of different accounts. Who can keep track of that? I think most people just end up, dangerously and arguably unethically, giving a service access to all their client/work projects, when they wanted it on only one of them.

In some cases github via Oauth or whatever is going on seems to give more granular access. I've seen it look entirely different (like entirely different screens) in different contexts I"m auth'ing some third party service. Maybe it's different historical APIs all still in use? I can't keep track of what's going on, it just all confuses me -- which makes it even harder to know if a service is asking for appropriate permissions or not, I'm not really sure what the possiblities are, they seem very inconsistent.

There's also two sides to this: services can ask for permissions, but I want to be able to only pretend to give them some - i.e. asking for all repos access should let me lie and say "no only things such match this regex or this security tag".

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.

It's not clear to me how that helps, but you're probably right it does. But I feel like some things have gotten access to a token via a web-auth procedure such that they have access to anything my account does, across organizations.

I swear I have seen flows that ask me to give them that, and don't let me even limit to certain organizations.

But I may be misunderstanding, for sure.

The real problem is that i just don't understand github's auth model for third-party api access. So I have trouble understanding what the possiblities are, what permissions I"m granting, and if they were the minimum permissions the app could have asked for or not. Every time I go through it, it seems to be different than the time before.

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 wording

[1] https://LayerCI.com

[2] https://github.community/t/why-does-this-forum-need-permissi...

I realize that the thread is even by the same author as OP as well!

For QA Wolf we created a separate GitHub OAuth app just to avoid this UX bug

I can confirm this. I just created an app with 0 permissions (everything set to "no access"), and the page looks exactly like the screenshot in the article.

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.

The wording of the "act on your behalf" message is very frustrating indeed. I don't like to think about how many app installs I've lost due to the wording of this message. I've had worried users query me about it directly, but presumably many more have just abandoned the installation without contacting me.

Here's another GitHub forum thread asking about it:

https://github.community/t/enable-you-to-trigger-actions-in-...

A trivial wording change would go a long way toward fixing this problem. Unfortunately according to GitHub Support (post 15 in that thread) "The current wording is not considered a bug."

:-(

BTW if anyone is wondering whether that advertisement board regarding password security is real and where it is -- it is real and it is in Harajuku here:

https://goo.gl/maps/Nbt1kNe4gZ8oyH1F8

It has been there for something like 10 years as far as I can tell and there are more than one (go up the hill and you'll see the others). It's pretty amazing that someone has taken what I would consider prime advertising space for privacy ads in the world's biggest city for ~10 years.

It's a meme (and a bit annoying when it's the only angle anyone takes on Japan), but Japan is indeed weird.

The biggest omission IMHO are project-scoped access tokens. GitLab has them above the bronze tier [1]. GitHub only has Personal Access Tokens, which grant access to all projects accessible to the user - scary!

Having project-scoped tokens would open up GH as a storage layer for personal data apps as well. Like a bookmarking app that syncs to your GitHub.

1: https://docs.gitlab.com/ee/user/project/settings/project_acc...

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.

I’m not sure when the Forestry-GitHub integration came to be but Forestry was launched in 2016 and GitHub Apps was launched in 2017.

Their problem (refined permissions / permission to a single repo) can seemingly be solved by migrating to GitHub Apps but, at the time they launched, there was no way for them to ask for permission to a single repo.

So now there are two problems: - GitHub Apps is a bit of a mess in terms of user experience from both the product side and user-facing side - Forestry has probably looked at this problem and said “we will make more money by losing out on customers who don’t sign up due to code access vs spending months refactoring the core concepts of our product”.

Eventually, GitHub will become more strict in OAuth vs GHA and then become more strict with what it allows on its platform (similar to what Google has done with Chrome extensions recently).

But at the end of the day, GitHub probably doesn’t care THAT much. If you don’t agree with the permissions, don’t install the app and/or put pressure on the product to refine their permissions. It’s tough to know the lost revenue due to these issues so give them incentive to change.

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 but there are tons that don't.

Let's say the requested permission is very straightforward like "append rows to your existing spreadsheets". It's also generally impossible to grant access using oauth to just a subset of whatever resource it is, like only spreadsheets A, B, and C, but not X.

I wish sandstorm had caught on much bigger than it had, it brings a fine-tune grained capabilities-based auth system.

Is there a problem using Sandstorm today? I followed it some years ago but never actually tried it, always too busy. :(

Only the same problem as using any other open source thing that didn't catch on: you have a smaller community to get support from, newer things won't be ported to your platform quickly or ever, and your chosen platform gets less adoption and becomes less compatible over time.

I stopped using Slackware when I got married / got a job / had kids, because debian made all my day to day management tasks easier and I no longer cared about knowing deep details about every single package that lived on my system.

I'll still install it and toy with it, but I'm not going to push my kids towards using a sandstorm word processor over google docs etc.

> But if you allow them blanket access to your github (or gitlab), YOU SHOULD ARGUABLY BE DISQUALIFIED FROM BEING A SOFTWARE DEVELOPER!!!

The author would probably have himself professionally disbarred if he knew what Disqus was doing with his blog. Which is why I think we should be more forgiving of mistakes than what his tone proposes. GitHub obviously has room to improve, but ultimately the system runs on trust, and sometimes the best we can do when it's violated is react to solve the problem and then write a postmortem.

Anyone who would abuse this overly wide access given to their org (by the dev) wouldn't make a single bleep about it and just keep scraping data and code quietly until the door is shut in front of their face. So I don't think your idea about how this should work is good.

If somebody wants to just shovel other organization's code into their silo then they are not incentivized to attack the current state of affairs; on the contrary, they are benefiting from them, why would they say anything at all?

> The author would probably have himself professionally disbarred if he knew what Disqus was doing with his blog.

I agree that we should be conscious of security in all things and apply universal standards but your comment comes off as a whataboutism and a discussion stopper.

We can and should address the security issues one by one. That a lot of things are broken does not mean we should throw our hands in the air and give up, no?

I think what we need is more along the lines of this blog post: https://opensource.googleblog.com/2017/03/operation-rosehub.... Modern tools grant each individual the ability to fix the world's code at scale. All we have to do is get our hands dirty creating the change we want to see in the world. Doing that effectively it helps to not assign blame since we all make mistakes and ultimately the goal is to improve.

This is a commendable initiative. From the article:

> With the help of GitHub’s GUI, any individual can make such changes to anyone’s codebase in under a minute.

Sigh, so yet again the load falls on the normal working programmers' free time. And yet again the effort is vastly underestimated. Sure it took 5-10 minutes (I doubt it took one, as article claims) this time but what about the next 50 times? The article even supports this:

> As more work was completed, it was apparent that the problem was bigger than we had initially realized.

I am glad several Googlers decided to help. I wish it happened more often with them and other corporations. The normal working programmers are overworked enough already.

You have a very negative way of looking at things. Spartacus was born a few miles from you and he was just an ordinary guy. Would he have needed to be a rebel had he been born today, in a time when the system gives each individual the tools they need to make the world a better place? I say why not use them.

Because there's a limited amount of hours per day, and even more limited joules of energy.

So I'll always disagree that such initiatives must be in one's free time.

Guess I am only looking at this as a job now. I do want to work on certain things but nobody is willing to pay for them, AFAIK at least.

Hah, I ran into this guy on the support forum thread about this issue: https://github.community/t/why-does-this-forum-need-permissi...

I'm on his side - I think the copy is bad - but he was pretty unhelpful in the thread and ended up getting it locked.

Since the author doesn't link to it, here's where you can manage your Authorized OAuth apps (warning, password prompt):

https://github.com/settings/applications

That page does not even show what permissions/scopes the Authorized OAuth apps have access to! (Or am I missing something?)

You're missing something. You can click the app name for a details+actions page for that app-grant.

There it is. I looked under the three dots, and didn't find it. I think I assumed that clicking the app name would take me to the app.

I noticed this problem a while ago when I wanted to use DockerHub’s automated image build service. Per the docs https://docs.docker.com/docker-hub/builds/link-source/ you need to grant DockerHub access to your entire GitHub organization!

For me, this was a full stop dealbreaker. A work around was to create a separate GitHub org just to use with the dockerhub build service, but frankly that’s a terrible hack that just masks the larger problem.

GitHub permissions are horrible.

I need to create repo specific tokens. If I integrate with some 3rd party CI tool, why must I grant access to all repos? Or can’t I grant read only instead of write and full control.

I have access to lots of repos and orgs, I don’t want to worry about everything getting hosed if a single token is compromised.

I also don’t like that for an org, I have to approve apps for anyone to use for anything. I’d like more fine grained controls to approve what they want to do, for the fewest repos necessary.

I noticed this before but didn't really give it much thought like "worst comes to worst they delete all my repos, so what?" but I realize now that someone could literally rewrite the commit history and inject a virus into a popular repo without anyone noticing. This is terrifying and definitely needs to be addressed.

One of my favorite is creating an API token for something that needs to read PRs and milestones. "Full control of private repositories" is the only option that works :D

SaaS CI/CD permissions are a bit of a mess too; not sure what the ratio of blame on that is though TBH.

Permission problems extend to other popular developer platforms as well and I wish more granular permissions were the norm. One example I encountered was with GCP, where I wanted to create a key that could only update a single existing DNS record but I discovered it wasn't possible to apply such strict restrictions. My reasoning for desiring such a restricted key was that if it was somehow leaked or stolen the amount of damage that someone would be able to accomplish would be far more limited than if the key had greater capabilities. Despite the Principle of least privilege [0] being a well-known concept, putting it into practice in real world systems often ends up being an uphill battle. With modern complex systems it can be very difficult to feel confident about the security of each component, and if your attack surface is sufficiently large then it's merely a matter of time before some part fails. We need to make it easier and simpler for regular developers to do the right thing without requiring that they setup even more complex systems which require extensive administrative knowledge in order to successfully accomplish anything with a modicum of security.

[0] https://en.wikipedia.org/wiki/Principle_of_least_privilege

The biggest problem I have with the Github auth flow is around organizations. An organization can prevent my apps from accessing its repos, but I can't deny an app permission to access organizations that I don't want it to. As a freelancer, when some client uses a Github app to do something, I have to give that Github app access to all of my other client's organizations, because Github won't let me disable them.

I would say make per-client Github accounts, but that's stupidly painful to manage too. It would be nice if they could do what Google does with multiple accounts being logged in being supported (though, that implementation has warts, too).

Yes, as a contributor or member of a few different technical groups with GitHub organizations, I feel the same way. Those groups don’t want me using app X on their repos, and neither do I!

The whole industry has a permission problem. There's this concept called the "principle of least authority," the idea that programs should only have access to the information they need to do their job, and no more. We are so far away from that it's not even funny.

Overbroad OAuth scopes are one example of this, yes. Here's another: consider all the dependencies you use in your applications as a developer. Any single one of those (perhaps hundreds of) dependencies can typically do anything you can do; it can rifle through your ~/.ssh directory looking for private keys, it can add stuff to your .bashrc, it can make arbitrary network connections, it can edit your browser settings. Likely most of them don't need to be able to do any of this. And yet that's what we accept in our computing environments, every single day.

Yes, it's incredibly dangerous.

This is what SELinux gets quite right under some configurations: that my home directory has distinct types of files and programs need to ask for very specific permissions to access some of them.

Though MAC schemes in the Linux world are incredibly fragmented these days and containers have just made that worse.

SELinux is a stopgap... it would be better for the system to provide a PowerBox to select files, instead of hoping your programs access the right files. It gives you far more expressive power and safety, and protects you from confused deputies or malicious software.

Some day we'll move to capability based systems, and I hope this means we can finally ditch the false idea that you can enumerate all the bad programs, and write ones that never go wrong, nor get confused.

Compromising a third-party to inject code into your public & private repositories is going to be a future supply-chain compromise similar to Solarwinds

Another problem is you grant access to all repositories. Say you want to use a ci service to build your software, you need to grant them access to _all_ repositories but you only wanted to use them for one project. Github permissions should have an optional opt-in feature to only let the provider see the repositories you want them to show.

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.

We use GitHub as a push only destination. i.e. We never pull from it, and we never deploy from it. Our master repos are internal and don't have an upstream. This ensures that our source code is secure. Code that doesn't need to be accessible to the public, isn't pushed to GitHub at all.

I ran into this recently on Gitlab. Gitlab has these amazing deployment tokens that can dole out read-only access to individual repos and yet if I want to deploy from a Gitlab repo to Netlify I have to give Netlify full access to all my repos. That's beyond dumb.

What is the best example of fine grain permission UX? Everything I’ve seen skews towards this style of overly broad permission. What are good examples that GitHub should learn from?

Not quite the right answer, but if you want fine grained permissions in an OS, look to Genode, or other capability based systems.

If you want to see another way to do it, check out the "guest pass" that Flickr lets you hand out... you can grant permission to read an otherwise private folder, and you can revoke it at any time, just like a read capability in a multilevel secure OS.

I’m not a Facebook fan in general, but this is something FB has actually nailed. They let you check and uncheck each permission or piece of info to share directly from the oauth screen.

Indeed. GitHub recognized this and allows security settings on orgs you're a member of (such as employers, clients, et c) to opt out of users' oauthing to random third parties (wrt access to that org's info). If you're a organization, you can whitelist the apps that users are allowed to use to access your org's code.

Then, when your devs log into whatever with GitHub, they're not forking over (access to) your org's source code to every random website.

GitHub Personal Access Tokens have no granular permissions. Coworkers always opt-in to use PATs instead of deploy keys, because it's easier, but to be able to clone a repo with PAT you need to extend the permissions way beyond just cloning a repo. The OAuth scopes are also not very granular. They don't have to reinvent the wheel - there are already a bunch of working systems they just need to replicate.

Blog writers have problem problems.

I'm not just annoyed by the title. The "problems" are generally feature requests sold as bugs.

The blog post describes a relevant security issue, especially given how many hacks and other issues we have seen over the last years with compromised browser extension repositories, widely-used npm packages and the likes.

And it's compounded by many years of users being trained to blindly accept the "Authorize user to do X Y Z" prompts all over the Internet.

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.

I was hoping this was about gists being publicly accessible even when they are private...

Is that true? Do you have a source for that?

If you try to make a gist you'll have the option of either "Create a secret gist: secret gists are hidden from search engines but visible to anyone you give the url to" or "Create a public gist: Public gists are visible to everyone"

Parent seems to have confused "private" and "secret".

They're not private, they're "secret". The descriptive text when choosing between "secret" and "public" says, "Secret gists are hidden by search engines but visible to anyone you give the URL to", though to be fair this isn't as prominent as it could be.

Given that private repositories used to be a paid-only feature and that gists as a feature haven't been substantially updated in the last 8 years, I'm not all that surprised that there isn't a "private" gist type.

https://docs.github.com/en/github/writing-on-github/creating...

> Secret gists don't show up in Discover and are not searchable. Secret gists aren't private. If you send the URL of a secret gist to a friend , they'll be able to see it. However, if someone you don't know discovers the URL, they'll also be able to see your gist. If you need to keep your code away from prying eyes, you may want to create a private repository instead.

Tangential, but Gitlab is pretty terrible when it comes to managing permissions.

Can we now talk about docker hub requiring write access to your repositories as well? This is an awful situation and tons of projects on github have given up on this front and just allowed full access to their repo

I don’t disagree with fine grained permissions, but something about the alarm is not logical because Github is already a third party you are trusting vis-à-vis your code.

Pull requests that kick off arbitrary Github Actions code is crazy unsafe. By default they need a human in the loop to approve CI jobs for public repos.

Perhaps if the blog was more straight to the point and with less adjectives, it would attract more attention.

The TL"TL;DR";DR is: "Thousands of developers are giving 3rd parties write access to their github repos (...) The tokens given to 3rd parties are just like passwords"

Reply on news.ycombinator.com