9 ms·

GitHub Has a Permission Problem

264 points by phreack 6y ago

nikolay 6y ago
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.
JMTQp8lwXL 6y ago
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 https://github.com/settings/applications
- jfoldager 6y ago
  That page does not even show what permissions/scopes the Authorized OAuth apps have access to! (Or am I missing something?)
  - derefr 6y ago
    You're missing something. You can click the app name for a details+actions page for that app-grant.
    - jfoldager 6y ago
      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.
woliveirajr 6y ago
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"
derefr 6y ago
> 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.
- l0b0 6y ago
  In other words, the problem is with describing secret information as "public".
  - derefr 6y ago
    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.)
hardwaresofton 6y ago
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 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.
- deleted 6y ago
  [deleted]
GongOfFour 6y ago
I was hoping this was about gists being publicly accessible even when they are private...
- ibraheemdev 6y ago
  Is that true? Do you have a source for that?
  - deleted 6y ago
    [deleted]
  - meetups323 6y ago
    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".
- re 6y ago
  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-gists#about-gists 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.
jez 6y ago
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/ https://plaid.com/
- niij 6y ago
  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.
- u801e 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - o-__-o 6y ago
    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.
caminocorner 6y ago
Compromising a third-party to inject code into your public & private repositories is going to be a future supply-chain compromise similar to Solarwinds
remram 6y ago
> 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...
- u801e 6y ago
  > 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).
  - edoceo 6y ago
    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
deleted 6y ago
[deleted]
jrochkind1 6y ago
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.
- XorNot 6y ago
  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".
- judge2020 6y ago
  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.
  - jrochkind1 6y ago
    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.
CGamesPlay 6y ago
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.
- gertlex 6y ago
  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).
- aaronharnly 6y ago
  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!
colinchartier 6y ago
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 https://LayerCI.com [2] https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453 https://github.community/t/why-does-this-forum-need-permissi...
- colinchartier 6y ago
  I realize that the thread is even by the same author as OP as well!
- jonperl 6y ago
  For QA Wolf we created a separate GitHub OAuth app just to avoid this UX bug
- ihuman 6y ago
  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.
- LysPJ 6y ago
  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-github/117938/12 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." :-(
- evanelias 6y ago
  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.
larrybud 6y ago
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/ 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.
deleted 6y ago
[deleted]
forrestthewoods 6y ago
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?
- mikewarot 6y ago
  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.
- nikisweeting 6y ago
  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.
deleted 6y ago
[deleted]
simon_weber 6y ago
Hah, I ran into this guy on the support forum thread about this issue: https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453 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.
DevoAKA 6y ago
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.
paxys 6y ago
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.png 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.
- fedorareis 6y ago
  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.
ryukafalz 6y ago
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.
- XorNot 6y ago
  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.
  - mikewarot 6y ago
    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.
- deleted 6y ago
  [deleted]
prepend 6y ago
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.
Rapzid 6y ago
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.
rileymat2 6y ago
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.
TheAceOfHearts 6y ago
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 https://en.wikipedia.org/wiki/Principle_of_least_privilege
jart 6y ago
> 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.
- pdimitar 6y ago
  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?
  - jart 6y ago
    I think what we need is more along the lines of this blog post: https://opensource.googleblog.com/2017/03/operation-rosehub.html 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.
    - pdimitar 6y ago
      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.
guessmyname 6y ago
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.
solarkraft 6y ago
Blog writers have problem problems. I'm not just annoyed by the title. The "problems" are generally feature requests sold as bugs.
- mschuster91 6y ago
  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.
Mistri 6y ago
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.
philsnow 6y ago
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.
- deleted 6y ago
  [deleted]
- pdimitar 6y ago
  Is there a problem using Sandstorm today? I followed it some years ago but never actually tried it, always too busy. :(
  - philsnow 6y ago
    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.
AcerbicZero 6y ago
Tangential, but Gitlab is pretty terrible when it comes to managing permissions.
sumanthvepa 6y ago
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.
jeswin 6y ago
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_access_tokens.html https://docs.gitlab.com/ee/user/project/settings/project_acc...
sneak 6y ago
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.
sriku 6y ago
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.
welder 6y ago
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.
tess0r 6y ago
q
INTPenis 6y ago
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.
tpetry 6y ago
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.
Jiejeing 6y ago
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
crb002 6y ago
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.

264 points by phreack 6y ago

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.

JMTQp8lwXL 6y ago

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 https://github.com/settings/applications

jfoldager 6y ago
That page does not even show what permissions/scopes the Authorized OAuth apps have access to! (Or am I missing something?)
- derefr 6y ago
  You're missing something. You can click the app name for a details+actions page for that app-grant.
  - jfoldager 6y ago
    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.

woliveirajr 6y ago

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"

derefr 6y ago

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

l0b0 6y ago
In other words, the problem is with describing secret information as "public".
- derefr 6y ago
  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.)

hardwaresofton 6y ago

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

deleted 6y ago
[deleted]

GongOfFour 6y ago

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

ibraheemdev 6y ago
Is that true? Do you have a source for that?
- deleted 6y ago
  [deleted]
- meetups323 6y ago
  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".
re 6y ago
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-gists#about-gists 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.

jez 6y ago

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/ https://plaid.com/

niij 6y ago
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.
u801e 6y ago
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.
- deleted 6y ago
  [deleted]
- o-__-o 6y ago
  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.

caminocorner 6y ago

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

remram 6y ago

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

u801e 6y ago
> 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).
- edoceo 6y ago
  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

deleted 6y ago

[deleted]

jrochkind1 6y ago

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.

XorNot 6y ago
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".
judge2020 6y ago
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.
- jrochkind1 6y ago
  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.

CGamesPlay 6y ago

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.

gertlex 6y ago
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).
aaronharnly 6y ago
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!

colinchartier 6y ago

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 https://LayerCI.com [2] https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453 https://github.community/t/why-does-this-forum-need-permissi...

colinchartier 6y ago
I realize that the thread is even by the same author as OP as well!
jonperl 6y ago
For QA Wolf we created a separate GitHub OAuth app just to avoid this UX bug
ihuman 6y ago
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.
LysPJ 6y ago
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-github/117938/12 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." :-(
evanelias 6y ago
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.

larrybud 6y ago

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

deleted 6y ago

[deleted]

forrestthewoods 6y ago

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?

mikewarot 6y ago
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.
nikisweeting 6y ago
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.

deleted 6y ago

[deleted]

simon_weber 6y ago

Hah, I ran into this guy on the support forum thread about this issue: https://github.community/t/why-does-this-forum-need-permission-to-act-on-my-behalf/120453 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.

DevoAKA 6y ago

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.

paxys 6y ago

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

fedorareis 6y ago
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.

ryukafalz 6y ago

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.

XorNot 6y ago
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.
- mikewarot 6y ago
  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.
deleted 6y ago
[deleted]

prepend 6y ago

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.

Rapzid 6y ago

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.

rileymat2 6y ago

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.

TheAceOfHearts 6y ago

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 https://en.wikipedia.org/wiki/Principle_of_least_privilege

jart 6y ago

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

pdimitar 6y ago
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?
- jart 6y ago
  I think what we need is more along the lines of this blog post: https://opensource.googleblog.com/2017/03/operation-rosehub.html 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.
  - pdimitar 6y ago
    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.

guessmyname 6y ago

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.

solarkraft 6y ago

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

mschuster91 6y ago
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.

Mistri 6y ago

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.

philsnow 6y ago

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.

deleted 6y ago
[deleted]
pdimitar 6y ago
Is there a problem using Sandstorm today? I followed it some years ago but never actually tried it, always too busy. :(
- philsnow 6y ago
  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.

AcerbicZero 6y ago

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

sumanthvepa 6y ago

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.

jeswin 6y ago

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_access_tokens.html https://docs.gitlab.com/ee/user/project/settings/project_acc...

sneak 6y ago

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.

sriku 6y ago

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.

welder 6y ago

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.

tess0r 6y ago

INTPenis 6y ago

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.

tpetry 6y ago

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.

Jiejeing 6y ago

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

crb002 6y ago

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.