I thought that he added his public key to the Rails user through his own account settings, which wouldn't give him access to the Rails web admin.
This is correct. People who don't understand what a mass-assignment bug is are running with this story. It's like when we witness a DDoS and have to tollerate people who think it means that the targeted party was infiltrated. This bug allowed one to add their public key to another user's account, and make changes to comments and issues.
I have lost all trust in GitHub, and not because of the vulnerability, but because of their response. With their suspension of hamakov's account and deceptive blog post about the extent of the hole, GitHub has guaranteed that they won't be the first to know about the next vulnerability (and there's always another). I've downgraded my paid account to a free account, and won't keep any non-public data on GitHub in the…
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)
I used GitHub and I'm not moving my stuff off. If an app gets hacked, then not long after, that app will likely be the most secure place. GitHub at least keeps it up most of the time. Who you really should be mad at are the Rails maintainers and the RoR community. I switched from Java to Ruby a few years back, and since day one, everyone using Rails has been slack on security. The reason is that they make things too easy to leave wide open. Don't believe me? Read the Rails official documentation for starting off. It is all about ease of use, not security. If you are new, you have no idea what you've really left open even when you just generate a scaffold as they show you to do. The main thing that Rails security has going for it is that the adoption of Rails is still relatively low, and because a newbie isn't likely to scale their app well, odds are you won't have an extremely popular, extremely performant Rails app that is just asking to be hacked that easily.
You're conflating two issues here. He's arguing that the Rails team was ignoring an important issue by noting it was an easy end-user fix, and GitHub overreacted by suspending him after he tried several times to bring it to their attention, and then grossly mislead their user base as to the extent of the issue (which sounds like a really fundamental security issue that any professional Rails developer should know how…
Fair enough. Ignoring the issue and not fixing it after it was brought to their attention to me is where they screwed up. 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 point…
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.
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.
I'm just going to latch on to this comment to make mention of a GitHub alternative for private repositories: http://repositoryhosting.com/ 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…
I've always plugged the here on HN before, and will do it again: http://www.assembla.com Unlimited private Git, SVN and Mercurial repos for free. We've been using them for years for all our projects with no issues.
I used to use them years ago and it certainly wasn't issue free. When they took away their free private accounts it was a pretty big pain only to have them re-implement them less than a year later.
I have lost all trust in GitHub, and not because of the vulnerability, but because of their response. With their suspension of hamakov's account and deceptive blog post about the extent of the hole, GitHub has guaranteed that they won't be the first to know about the next vulnerability (and there's always another). I've downgraded my paid account to a free account, and won't keep any non-public data on GitHub in the…
^ this, I just moved my prive repo to bitbucket hoping that Atlassian would have handled this issue better. At least they seem to have more experience looking at their long history in software. I will also look into setting up my own git(orious) server.
I personally know some people that work for Atlassian and they are awesome. Moreover, they really do care for their customers. I have no experience using Bitbucket, but given the people I know I would definitely trust them.
I guess it's just about familiarity. We do have the tools (mdns/avahi/bonjour, tcp/netcat, ...). But the internet is usually up, so we don't need to learn how to set up our own local servers, and there's no punishment for transmitting a file across the atlantic when it could have been transferred to another room in the same building and back again.
The fact that there is not persistent caching of mission dependent code and data as a fundamental commercial standard shows how badly we as a species in general can judge risk, even when the stakes are really high.
How so? Each git user has a local copy of the whole repository.
FWIW, that last bullet, aside from being the most egregious example of hyperbole in TFA, shows a complete lack of understanding of how git works.
Nothing in the article would lead one to believe he didn't understand the distributed nature of git repositories, but a lot in the article would lead one to believe he was specifically referring to the data loss issues on GitHub if someone wiped out a project.
If the project was deleted from Github, you'd just have to create a new one push a local clone to it. That's hardly what that point is saying.