GitHub and Rails: You have let us all down.
chrisacky.posterous.com
chrisacky.posterous.com
Guy drops a zero day on a major service provider, guy gets his account suspended (temporarily, it turns out). In what possible world is disabling an account that has recently exploited your live product in a very visible way not ok? Remember, you don't have a chance to call a meeting with the C level guys and your community manager - you're one or two guys responding on a weekend.
The rest of the "oh my god the sky is falling" drivel about how terrible a bug it could have been and how they should never have had such a vulnerable bug in the first place is even worse. Security bugs are fuckups by nature - nobody sat and said well shit I was going to code this wrong but since it might allow a lot of access I won't. In terms of OH SHIT bugs this is actually rather small - I'm sure github's live infrastructure has been open to lower level remote execution vulnerabilities over the years - newsflash: we all have been. Getting user or superuser or db admin is going to almost certainly be a lot worse than an application authentication level vulnerability.
You say none of that matters because it's such an obvious bug and people have known not to do that kind of thing for years? Say hello to our old friends "buffer overflow" & "use after free" - still grabbing msft aapl & goog after all these years.
TL;DR - stop acting like children.
Bugs happen. Even stupid oh-my-god-i-can't-believe-i-did-that bugs happen. And they happen to the best of us.
However, when someone reports a vulnerability about my code to me or I discover a problem myself, the very first thing I do is break out the grep. I grep the shit out of my code. Because I am a human being. I am a creature of habit. And if I screwed up in one place, I promise you, I did it in other places too.
The problem? Github didn't do that. At least, that's the impression from the information coming out. The guy reported the issue on Friday, they fixed that specific instance of the issue ... and it remained a problem in other places. That is unacceptable and unprofessional. They should have burned the midnight oil and made sure the same problem wasn't prevalent in other parts of the code.
Having said that, I am a loyal Github client and will remain so. Every service provider I use gets a once-a-year-screw-up credit. Github just used theirs. Switching because of one incident is premature and will be sure to cause regrets.
I understand that's the feeling here, but it's unrealistic. I've reported dozens of bugs to shops that ranged in size from 1 to borg. You simply never see a whole set of bugs fixed and pushed live over a weekend. Not even close. Exactly what company have you seen set this standard for professional? The smallest amount of time between notification and public disclosure I've seen get called responsible disclosure is a month. Many, many, many enterprises take six months or longer to push fixes (which is far too long but that's another whole discussion)
However, if such a problem was reported to LedgerSMB here is how we handle it:
1) Scope out the problem. What's affected? Are other related open source projects affected? How bad is it? This itself can take a bit of time. We do not rush this because we don't want a full disclosure when it happens to bring other problems into the fore.
2) Within a few days we let the reporter know what we have found and give them a chance to offer feedback.
3) Then we get everyone on the core team together and talk solutions. Once we implement it, we test and release a patch. Two weeks after the patch is released, we release a full disclosure along with a hat tip to the one who discovered it.
The whole process takes time. But the fact is that it's generally better to get a full fix out in two weeks than a partial fix out tomorrow.
So no, don't burn the midnight oil. More speed, less haste.
And this whole thing really doesn't look good for Github.
I definitely wanted to do a more careful audit and investigation, but my hands were tied.
More importantly people reading this forum are very scanty in the larger picture of people writing software around the world. Software and tools get used in 99% of cases for average programmers because of jobs,popularity and usability reasons.
I bet of all the Rails programmers, and Git hub users very few would have heard the news. And of those few who have heard it very few would understand the seriousness of the issue.
The only benefit that has come out of this, is a serious problem has been averted. If this vulnerability had been discovered by some body who makes his bread and butter cracking systems. He could have done a great deal of damage to a lot of systems.
Lets hope that Rails finds and fixes these sort of vulnerabilities. To avoid bigger problems in the future.
If I have correctly understood the issue, Igor at first informed Rails, and this was the right thing to do. He was ignored by Rails and then he wanted to proof his view point by applying it to GitHub. How could GitHub inform other places? By contacting Rails, but they already downplayed the issue...
"What I want you to see in that thread I mentioned is the way the core team perceives this. You are not discovering anything unknown, we already know this stuff and we like attr protection to work the way it is."
(https://github.com/rails/rails/issues/5228#issuecomment-4292...)
After reading for how long he tried to bring attention to this and only got a top guy to say that kind of stuff. The guy who hacked is not right in any way but I don't even have words to describe the person who wrote the above line.
I'm not condemning anyone, but it seems that when someone points out that your framework ships Insecure By Default code with absolutely no warning in the generated code, you'd take that seriously.
Instead, the thread is full of "We've discussed this before, we like it the way it is" and "Rails is not responsible here."
I am not a rails developer, but I am pretty sure this would have woken up a lot of people for a lot of similar issues, there will be a mad flurry of devs rechecking a whole bunch of code. Had he reported this disacreetly what are the chances of this much publicity have been generated?!?
"Weapons of Mass Assignment" by Patrick McKenzie, ACM Queue, March 2011
http://queue.acm.org/detail.cfm?id=1964843
Worse, ten years ago PHP changed the default behavior after suffering from very similar problem:
http://www.sitepoint.com/write-secure-scripts-php-4-2/
Rails actually needed Egor to initiate change. At first they ignored him:
https://github.com/rails/rails/issues/5228
Now the change can be seen:
Nope, this bug is exactly what he used for his demonstration (and there are warnings about attr_accessible going back 3 or 4 years, so it's not a "0-day" by most accounts, more of a "3-years"" vuln)
The rants that are coming in are not about what has happened, but what could have happened.
Imagine a situation if somebody had deleted all the data or worse committed malicious code to important repos. And then used it create a bigger mess later it would have been disastrous.
If this can't be taken seriously I don't know what can be.
Should they have shut down github.com entirely. Tweeted in all caps every 15 minutes until they fixed the problem? Called a televised press conference? What?
I'm just pointing out the seriousness of the situation.
Punishing Egor Homakov in this case is a classic example of 'No good deed goes unpunished'. Had this vulnerability been found by somebody with evil on his mind. We would be having a very different debate now.
We all make mistakes. And I don't really blame Github for this. But we must at no cost downplay this incident.
And discussing about this will only do good.
The LedgerSMB project started in a similar shitstorm. I found an ability to forge credentials in SQL-Ledger. I submitted it. I went back and tried a month later on a new version (no communication from the SL author) and it was a little harder but not too hard. I exploited again, sent another email, was told to bug off.....
I tried to get the issue fixed for six months. I finally gave up and forked. When we forked we issued a security advisory publicly and stated we would offer a full disclosure soon. That's when the shitstorm started in earnest. I was accused of fearmongering. I was told I didn't understand security, that the software was plenty secure, and many choice lines that out of professionalism I will refrain from reposting to this forum.
Dozens of emails.
The end result was that Dieter fixed SQL-Ledger shortly after the fork, because those who stayed behind made him. It would not have been fixed without the fork.
Sometimes you have to be confrontational.
Because no good deed goes unpunished. No one appreciates what good caused by your help.
It just bruises peoples egos and they violently lynch you for 'How dare you point a mistake at a genius like me, you should have tried whispering in my year'.
Its for incidents like this people refuse to help in not just security situations but also in emergency situations because you get entangled in unnecessary mess. People just let the world burn.
Doing it by demonstration on a live product without asking first is not as fine.
"I demonstrated how insecure your house is by picking the front door lock and leaving a note on your bed."
Sometimes it can be difficult to have the empathy and perspective to see how frightening and unconscionable the 2nd action can be, but it very much is.
Empathy was casusing me pain everytime I saw you 'lock' your door with that elastic band. Attention seeking or malicious behaviour would have been to break into all the insecure doors on the street.
I broke into yours, so you would take security seriously, because I care about you and your wellbeing."
The problem here is that when you violate someone's trust you change the landscape. People get scared, they question your motives, they go into a fight or flight response. Yes, this sometimes results in the problem being fixed faster because they are very much more motivated now, but the same is true if you kidnap their family, right?
If you think someone is letting down their customers by not responding fast enough, then you go public. But violating trust is a quick way to end a professional relationship.
This is breaking into a huge commercial factory with thousands of clients, where you could cause colossal damage, and only leaving a note.
Exactly, you and every other hacker with out there. At least you had the good conscience to leave a note.
This was anything but a zero-day, and that's the whole reason people are mad. Homakov very clearly made an effort to get this patched before exploiting it before taking action himself. They're not mad that it wasn't fixed immediately on Sunday; they're mad that, on Sunday, there was still a problem in the first place. Big difference.
I also don't see how you can blast Github for its oversight of this issue but then defend the "hundreds of thousands" of sites that use Rails. Aren't they as culpable? Oh, I suppose Github is held to a higher standard than the rest of the dependent apps. If this is Github's fault, then it is also every other developer's fault who doesn't by default disable mass-assignment of attributes.
If he didn't actually contact github directly and just assumed they would see the rails issue on a weekend, then I wouldn't exactly call it 'notice'.
If he did submit it to github via the proper channels before taking action, and nothing was done within a reasonable timeframe (eg. not just an hour or two on a sunday), then what he did would make a bit more sense.
https://github.com/blog/1068-public-key-security-vulnerabili...
Makes it sound like a separate issue.
edit: looks like github clarified https://github.com/blog/1069-responsible-disclosure-policy
https://twitter.com/#!/technoweenie/status/17645071550868684...
...though as they've now unbanned his account (good on them), it's somewhat moot.
As for the account suspension, I'm not sure I agree that the account should not have been suspended. Github is a code repository first, and I don't think they have an obligation to keep people around who are exposing security flaws by notifying the entire community. As the author of the post points out, hundreds of thousands of apps rely on Github, so to an extent it is their responsibility to block people who may jeopardize their users. Let's say that they left his account active, and then two months from now he exposed a larger security flaw by greatly damaging a users' app or business. I'll bet there would be more posts like this one blasting Github for not suspending his account. Personally, I think they should offer him a job.
But they haven't blocked him. They blocked his account, so all he has to do is create another.
Github has put their users in far more danger by being dicks to a guy to gain nothing.
Who said they did?
The best they can do is suspend his account per policy while they are investigating.
Why? What's the point of suspending his account?
There are two issues with any exploit: (1) prevent future exploits and (2) making sure that whoever discovered the exploit hasn't retained any unauthorized access.
Fixing the bug addresses (1) and suspending his account gives them time to address (2).
Suspending his account wouldn't have affected him if he was being black hat about this. A suspension in this case serves pretty much no purpose other than to make Github feel better about themselves.
"we already know this stuff and we like attr protection to work the way it is." https://github.com/rails/rails/issues/5228#issuecomment-4292...
I've downgraded my paid account to a free account, and won't keep any non-public data on GitHub in the future. I had a similar response with my (non-paid) DropBox account. I guess I didn't rationally evaluate cloud resources, and have trusted far too many people.
The way GitHub reacted (blocking @homakov) is just wrong and destroyed all my confidence in them. Even more so when it was pointed out that @zedshaw crashed GitHub and didn't get blocked. http://sheddingbikes.com/posts/1306816425.html
Edit: Given that they have now stated that suspending @homakov was only temporary I no longer bear any ill will towards them.
I'm still disturbed by their security practices though. I expected better by the github guys and I don't like what this implies about the rest of their App. (And yes I am using attr_accessible and not attr_protected since its inception)
Edit 2: See here http://news.ycombinator.com/item?id=3664839 My worst fear that GitHub is using unsafe mass assignment everywhere was NOT confirmed.
https://github.com/nickmartini/dongml
Which has:
https://a248.e.akamai.net/assets.github.com/img/b0de87a4cf0c...
If I was a woman there'd be an international shit storm over that image, but I'm a dude, and one that TPW hates, so of course they won't do shit.
Then again I can usually handle myself so that's what I did.
And github forgetting the block user functionality makes me think they don't want to listen to user needs. Sure, it may not be a very popular request, but I bet for a minority it's the most important.
There was a time when CGI and Perl were synonymous. You won't believe how many people have a similar opinion about JQuery and Javascript these days.
A few days back I wanted to use a object oriented language for a big project. Generally I straight away go and use Perl for all my experiments. But since this time I wanted Java programmers to be working with my project later I thought let me use Python as its more syntactically closer to Java. When I started coding, my manager peeked over my shoulder and asked if it was Python in which I was coding I replied yes. He immediately asked me to stop writing in it, as he thinks writing in 2.x is waste of time as it is going to go away, 3.x is not yet having all the libraries. And writing 2.x will force a huge rewrite effort later. I tried and reasoned enough to convince other wise. But alas, it didn't fly.
That is how it works with pointy haired managers. They read something some where and then hold strong opinions about a particular technology.
As programmers we can try and educate people in forums like these.
But managers don't read these forums. They are likely to read magazines from IBM and Oracle, where XML's are glorified and eclipse is presented as the biggest productivity booster ever. Unless we get a forum on such magazines, we won't be able to make much difference.
For sure I think that a language shouldn't be avoided for something different than technical reasons, and nothing else.
Haha what. Do you maintain any sites? Tell us what ones. I want to warn all of your users that the admin is someone who will disable an account of someone who committed to master on a project that is not theirs and feel he has accomplished something.
http://twitter.com/#!/homakov/status/176476394455437312
"Thank you all,sweethearts! For support, and shit too. One more thing to clarify. That tattoo is kind of fake made with henna. eat vegetables"
If he was, he wouldn't have really made his point, would he? There are a lot of other Ruby sites which have this sort of bug.
I actually do understand suspending his account, and I even kind of get the intentionally misleading communications (you have to keep the corporate customers happy, right?), but the new "white hat" policy thing is kind of silly, because that's clearly not what this was about.
EDIT: On second thoughts, I think I am being overly critical on all parties. Instead, I think I hands up "we messed up, but we are learning" approach would be better, and we see how both sides act if/when this happens again, lessons learnt and all that!
I've been a happy customer for a while now, and have seen them recommended on HN many times. You get unlimited repositories with unlimited users for less than the cost of GitHub's cheapest 5 repo plan.
My open source code is on GH, but it's all also pushed to RH, along with all my private code.
I know it can be a faf to setup proper reliable secure backups and so forth (though with git it shouldn't be too hard give the whole thing is designed with wide but efficient distribution in mind), but if you stuff is sensitive enough (in a business sense, some other financial sense, or for more personal reasons) to care about keeping private then I would think twice before trusting a third party with the data. No matter how trustworthy, reliable, and secure they try to be, every one makes mistakes.
Maybe I'm just paranoid. Or just plain old fashioned. But "everything in the cloud" just scares me. Keep public stuff on public services by all means, but keep your private stuff under greater control.
On contacting them I was told it would be fixed in a day or two, and that it was no big deal since you had to guess the URL. The values you had to guess in the URL were a ticket number (they start from 1), a repository name, a date (YMD) and a filename. Sure there is some variety in there but it is not in the billions of possibilities, just hundreds and that won't make any computer break into a sweat and in my words at the time "easy". To make matters worse you can't delete the attachments to tickets.
This may not affect you. It certainly affected me. For example we had some keyfiles in one ticket. Coredumps in others.
Two weeks later the issue still hadn't been fixed and I don't know when it was. I've never seen disclosure of the issue. There wasn't even any way of knowing if attachments had been accessed in an unauthorized way since there was no checking in the first place.
What makes you think I think that?
It's $6/month to take care of my most important assets. That doesn't even buy a meal at McDonalds anymore; it's worth it.
BitBucket is owned by Atlassian for 2 years now and they don't look like they're about to go out of business ($60mil revenue in 2011, 400employees, worldwide offices). When they bought it, it was them who set private repos to unlimited (when @jespern was running it alone, it was set to 5), so I believe they know what they're doing and that it fits their business model. Over 5 collaborators need a paid plan and that's just how they set up the pricing scheme.
As far as I can see as an active user and lurking through their blog and bugtracker, BB is actively developped, so I assume you don't have to worry about them running out of business, looks like it's a valuable asset in Atlassian's software portfolio (at least valuable enough to work on it).
Yeah, and people payed GitHub to host their private repos --how did that go?
Unlimited private Git, SVN and Mercurial repos for free.
We've been using them for years for all our projects with no issues.
Nowadays you can hand a CD, plus a printed manual. Printing the code is now optional. But you still have to register every version :)
But then, going so far to say losing all trust in github.. there was a bug, it's fixed and they suspended the "attacker". I wonder what will happen in the following days with script kiddies trying to "hack" all rails website. In fact, isn't the overloading of parameters something as old as the earth that security experts would check first as a vulnerability?
I don't mean to diminish the severity of this exploit, and the impact it has/could have had if left unchecked.
BUT, isn't one of the biggest perks of Git the fact that it's a distributed SCM? It's not a service where you must trust all of your data with the one provider, who might go belly up at any point and take it with them.
Yes, GitHub provides some fantastic social features and helps with community involvement through these features, but if you are dependant on a "single service" and you're using a DSCM/DVCS, you should probably look at a few alternatives to reduce that dependancy.
Transmitting files via Google's email servers from two computers on the same network in the same office in the same room, especially if you're in europe (ridicilously far away from GMail's servers) instead of directly between the computers on the local network is one of my main pet peeves..
There's nothing "broken" here.
The problem is that source code is incredibly valuable and often represents many man-years of effort. A competitor could use this to bypass a lot of the early architectural fumbling around that we all do. Also, source code often contains passwords and shared secrets like Facebook secret keys. Disclosure wouldn't be the end of the world, but it could certainly be disastrous for a lot of companies.
FWIW, we do.
You should always have to worry about these things, regardless of who's hosting things. It just so happens that Github, to date, has been checking the boxes in these areas and has established a reputation for doing so.
But, if GitHub losing your repo/having it trashed beyond repair will kill your project (or severely hamper it), the cost of setting up a second Git server and a couple of hooks to mirror your push is very low, in both dollars and man-hours.
I think there's some truth to that :)
Update: Apparently it's doable with some API magic, but you still have to handroll your exporter: http://www.lornajane.net/posts/2011/github-api-issues-list
Organizations should be expected to make decisions using reasoning that amounts to more than word association, e.g. he "attacked" us, so we'll "suspend" him.
As for Github's responsibility: Github failed to protect people's data the minute the bug went live. That data was open to Egor since the moment he discovered the bug until the moment they fixed it. Making a silly commit did not make anyone's data more or less vulnerable, so I don't believe that "taking this shit seriously" implies flipping out over it.
I'm not denying that by doing what he did it certainly got the word out and made everyone understand how serious of a problem this is. It was a very good point and I think the outcome is the right one. I'm just saying that Github's actions - to suspend the user who somehow got SSH rights to the rails org - is the right thing to do. They want to minimize his damage that he will do, and until they can do a full audit and understand how his commit got there, it's the right thing o do.
> Making a silly commit did not make anyone's data more or less vulnerable, so I don't believe that "taking this shit seriously" implies flipping out over it.
I fail to see how suspending a user is "flipping out" over it? I don't think you can color unauthorized commits to github repos with different levels of responses from Github. That's a dangerous line to walk IMO.
The latter violates the Computer Fraud and Abuse Act, creating huge imprisonment and employability risks.
My comment was to discourage such spectacular glory-seeking behavior by other people that claim to be trying to help. It's a serious crime, and the FBI does not care that your intentions were good.
I have more of an issue with the Rails team for not accepting that this "feature" is a massive bug that they should've changed ages ago, though.
It is pretty obvious that he did not have any malicious intent, nor intended to do damage (if he wanted to, he could've done massive damage from an anonymous account in ways that wouldn't draw attention to it).
The only thing suspending his account accomplished is to punish someone who has helped draw attention to a very serious problem.
It just comes across as an incredibly childish and petty response given the circumstances.
He was ignored by the Rails devs, not by GitHub. Yet GitHub became the target of his attack, because he was "bored" (his word, not mine).
At no stage, as far as we know, did he raise the issue directly with GitHub. As I've said in another thread, he could have done so and requested they disclose the fix publicly (say, within 24 hours) in an effort to force the Rails devs' hands. Instead, he's punished GitHub (who, mind you, probably should have audited for this vulnerability a long while ago) because he was shunned by the Rails devs.
https://github.com/blog/1068-public-key-security-vulnerabili...
Shutting down the one account will do nothing. He can create a second account in a matter of seconds. They fixed the code that permitted the exploit, right? So the fix alone should be plenty to prevent any more malicious attacks.
And now, because of the suspension, they have a wave of bad PR (justified or not). This guy is clearly infatuated with Github. He got a tattoo of the Octocat for crying out loud. Why would you punish this guy for loving your service and caring enough about it to warn you of a security vulnerability?
Seems like there are only minuses to suspending the account, not a lot of pluses.
I would think having a suspended GitHub account would be the least of worries with a company who has presumably access to a good lawyer or two and boatloads of cash...
> ...this episode has been handled is a face-palm fail of epic proportions.
I'm all for, like, the evolution of language, but can we please all, like, agree that 'fail' isn't, like, a noun, and 'epic' is, like, totally overused.
Github is obscure enough to non-developers but quite well known in the development circle.
This means if you are using github you probably have a damn good idea what the vulnerability is. I'm not a rails developer (mostly python/django) but I get it immediately. This is mostly an issue with the framework helping me shoot myself in the foot.
Sure it's in the documentation. But realistically a good framework gives me sensible defaults so I don't have to refer to the documentation. I trust the framework does the "right thing".
Never used and never will. What's strange with that?
I can't believe he actually put SVN and Mercurial on the same side, or that he implies that not using GitHub must mean that you don't use Git at all. This sentence is wrong on so many levels. Sigh..
I'm strange, for my actual work I use Mercurial hosted on BitBucket.
- Every GitHub Repository could be access by anyone as if they had full administrator privileges.
- This means that anyone could commit to master.
- This means that anyone could reopen and close issues in issue tracker.
- Even the *entire* history of a project could be wiped out. Gone forever.
This bug allowed one to add their public key to another user's account, and make changes to comments and issues.
What would be more bad is if this vulnerability allowed an attacker to get unauthorized read access or pull/clone access to a private GH repo.
Can anyone clarify for me whether this was possible?
Breathe.
They've delivered so much value over the past four years for me that I can forgive them this and I'd still have (a little) goodwill towards them left over.
Posted "almost 8 years ago" ie. posterous would appear to have the same vulnerability.
First, the statement, "Rails. You clearly messed up." is self righteous bullshit at its finest. Rails didn't mess up; the programmer(s) at Github messed up. No conscientious developer lets the end user mass-assign variables carte blanche. But with that said, _every_ developer messes up every now and then despite their best efforts; some times they mess up in a big way.
Secondly, if a user discovered a vulnerability in something I wrote, and they handled it like homakov did, I'd ban the shit of them until I knew for sure that they weren't a threat.
Finally, Github handled this exactly the way many companies would handle it: it's called damage control. These guys are really good at what they do, they provide a great service and they offer-up a lot of their tools to the FOSS community.
Exploits like this are worth a lot on black market. They are worth even more if you provide a precious and vulnerable target to go along (github).
It's like no, you should have to turn the server on in the first place. The fact that it took some Russian kid in his basement breaking into the github rails master for this self evident truth to be realized by the core rails team is totally outrageous.
You are vulnerable to someone else's fuck-ups as long as you insist on giving up control over your data and code in exchange for the convenience of someone else doing the "hard work" of development and administration for you.
Hell, restore the network to being peer-to-peer rather than hierarchical, and hosting your own whatever will no longer be such a damn problem.
Github did have a bug and noone knowledgeable about Rails appears to have made even a cursory inspection of the security of their controllers - which is where attribute protection actually belongs, since different controllers and different users change different attributes. Protected attributes is a blunt tool for simple situations, which is why it's not enabled by default. Github had a pretty terrible bug, discovered, and fixed it. They may not have handled it perfectly, but the certainly don't deserve this sort of mon hatred - any competitor you go to is likely to have security flaws as well, perhaps more severe and subtle.
@homako didn't just expose the bug in github, he exploited it to make an unauthorized commit to Rails master. His account most certainly should have been at least temporarily suspended as GitHub had no idea what else he might do to prove his point.
So basically, most of the comments here are glaringly wrong or ignorant bandwagoning, and it makes me wonder about the accuracy of information here about topics I'm less familiar with. A sad day when you realize all this intelligent discussion you thought you'd been reading about new topics was probably just grandstanding by eloquent fools.
For all the free fun you can have on github, they are in the business of selling private repositories. What could possibly have been worse than someone finding a bunch of bugs in a matter of days just to prove a point about Rails?
For all that GitHub has given to the developer community, an innocent mistake even of this proportion of incompetence is still should not evoke such hatred. And those upset about someone's account being suspended who was actively misusing security holes - well, maybe you should use a provider who looks positively upon reporting security holes by vandalizing customer data. And they suspended his account for only a few hours! Unreasonable? Hate inspiring? Outrageous? I think not.
And by the way, the fact the "issue" of the default had been reported 4 days earlier in a github issue tracker for Rails (which is certainly not followed, let alone on weekends, by github employees) does not in any way impact whether GitHub should have been aware of this vulnerability, and to suggest so is intellectually dishonest.
How many companies get hacked regularly like this but keep it under the rug? You think FaceBook's never been exploited? TurboTax? Mint? Stripe? PayPal? Shopify? Tumblr? Pick your app that "so so so so many businesses" use regularly, and I guarantee something like this has happened with all of them.
But were they open about it?
GitHub's been open the whole time.
Your post is like saying "All criminals are stupid". This is ridiculous, as the only sample you know of and can work with are the criminals who have been caught. You don't know how many other criminals are out there getting away with their crimes, because...they haven't been caught yet.
Who knows how many other companies have had hacks like this in the past two months alone, for example? I don't, and neither do you.
But GitHub, as an open, honest company that so so so many of use regularly (which means we know right away when there's a problem, especially with a hugely popular repo like Rails/rails) has been in the spotlight since the second this happened.
GitHub, in my opinion, has acted really cool about this. They addressed the issue, explained what the issue is, patched the hole, and even reinstated the hacker's account. DHH addressed the issue in twitter, other people in the community have admitted they fucked up, and now we as a community can work on fixing this.
That doesn't sound like "Letting us all down".
Someone who expects everything to work perfectly all the time and have no vulnerabilities is someone will be let down by anything, a pessimist, and stupid. And certainly not worthy of the front page of Hacker News.