This is the biggest problem with the article - if you're using GitHub as a reason to argue that Git is bad, then you don't know enough about what Git really is to make that judgement.
The fact that Git is a DVCS has nothing to do with the fact that the Rails developers failed to fix a bug on their platform (Rails), which the service that you happen to use to host Git (GitHub) happens to use as well.
Sure, you could use this as an argument to switch to another Git hosting solution (BitBucket, self-hosted), but this could just as easily have happened with a SVN host using Rails....
I honestly don't find this reasoning very convincing. Mostly because it seems to be mistakenly equating Github with Git. All of the issues presented on both sides (i.e. "why are we depending on this third party" and "I don't want to go back to <propriety whatever>") could be addressed with an in-house git repository. Sure that creates new problems, but if the concern is about using Github turning things into an argument about Git is just wasting time.
Also, statements like "Listen, Github is how software is done right now" are just screaming for unnecessary confrontation and useless sideline arguments. I agree that Git is more effective (for most use cases) than any centralized VCS I've seen, but turning that opinion into a bald assertion is just going to cause arguments you really shouldn't be having.
GitHub is great because you get to use git. I don't think that you can entirely separate them from each other, or craft an argument for the advantages of GitHub without somehow mentioning git. The vulnerability in GitHub clearly matters. It was a potentially explosive issue, but GitHub issued a prompt and appropriate mea culpa, while resolving the problem. Also, it stirred the pot in the Rails community, with many coming up with safeguards against the potential mass assignment vulnerability. Although I disagree with his downplaying of the problem, I certainly don't have plans of going anywhere else, which I think is the spirit of what the author was trying to convey.
That's exactly my point. The article seems to be confusing a concern about Github for a concern about Git and then spends most of its time addressing the latter. I can (and do!) use Git without using Github. If my organization decides that Github is too much of a risk, that doesn't necessarily mean we'll be dropping Git.
I found the same thing, the whole article is incredibly weak.
He asked with a sort of cocky, corporate assumption that I too was as appalled as he was at the blantant disregard for security [...] it was clear from the way he was talking about version control that he longed for the days of centralized control where one guy had to manually merge in everyone’s changesets
There is a gigantic gulf between being appalled at github's security and wanting to go back to the days one guy was merging all changes by hand.
it wouldn’t be tough to convince some manager-type that this Github thing does deserve a second-look.
Maybe thats because it is worth taking a second look? Who's going to be convinced by a laundry list that boils down to "shit happens, luckily nothing bad happened this one time and it could never be completely catastrophic"? Thats a incredibly low bar to set. I love github, its well tailored to be a host for an open-source master, but not for private stuff; even if we were willing to host internal services outside the trusted network, I certainly couldn't trust github.
Point 7 is dangerously wrong. The vulnerability allowed a malicious user to commit code under the identity of a a friendly user. The attacker could not have altered history, but he could have pushed his exploit on top. Chances are that it might have passed as a legitimate commit by that person.
That's assuming nobody ever looks at anyone else's commits. Inserting an exploit into someone else's software by pushing a new commit on top is extremely risky, because it's highly likely that someone will actually look at the commit and notice it's doing something wrong. Inserting malicious commits into the history of a repository is what an attacker would love to do, because nobody is going to pore over the old history of the repo, and this is exactly what git is going to prevent.
I don't trust the "many eyeballs" approach anywhere near that much. I doubt that a lot of people will look too closely at something dhh supposedly committed, and even if they were worried by what they saw they may put trust in the system (and the "developer") and decide that they're simply misreading it.
Bottom line is "someone will probably see the exploit" is a gambler's approach to security.
Well, take a shotgun approach, insert vulnerabilities in multiple repos. Or obfuscate the attempt - insert a small vulnerability in one of the libraries that rails uses (let's take a mailer lib) and that only gets triggered when certain obscure preconditions are met and then push a commit on top of rails that creates the required preconditions. Instant exploit - and each commit by itself may very well look innocent. Or spread the exploit over multiple commits, each one innocent enough, each one with a different user. Be creative, you'll find a way. And even if it's caught, then the risk fingers pointing at you will be minimal.
> “Those DVCS kids, they got just what they deserved, won’t it be great when we can get back to a real VCS like Perforce”.
This entire article is based on the false dichotomy that either we use get along with github as it is or go back to svn.
Given the number of projects which directly pull code from github and execute it on production machines, it is not unreasonable to expect basic security from a hosting provider. I don't see why github should be given a second chance.
It also conflates DVCS (specifically, git) with the attack at Github. The security incident at Github had zero to do with DVCS in any way, shape, or form. Were Github to have been SVNHub, built on Rails, and lacking mass assignment controls, the same attack could have occurred.
> This sort of stuff happens to every hosted service you
> use, 95% of the time you don’t hear about it because it
> is a real hostile and the company just pays some ransom
> demand in exchange for not being screwed.
Or you don't hear about it because the hostile is quietly making hay from the vulnerability in some other way. Like spying on private github repositories. The fact that github was hacked "by a friendly" doesn't mean it was only hacked by him.
I believe GitHub was able to tell which public keys had been added using this exploit (because with this vulnerability, the log files should still be intact). So we/they can safely say that this vulnerability was not exploited maliciously.
Sure, there may be others we haven't heard of, but that's potentially true about any service.
Why are we still talking about this? Besides the reasons listed are flat out wrong in multiple places. Not sure if it's the result of seeing the PR a week, two weeks later... 1 is completely moot. If a friendly can hack it, so can Somalian pirates. 2 is just inaccurate. 3 is applauding something that should never be necessary. 4 is missing the point entirely, as is 5. 6 is just stupid, it's not a response to "host your own Git repo".
"GitHub is a DVCS". Is the author aware that GitHub is... just Git... and that people can host their own Git repos manually? (Or their own mini-GitHub clone gitlab?)
Github wasn't hacked. Github had a programming error. The RAILS docs clearly state to be careful of mass assignment. It's a known issue.
Your product is only as good as the people who build it. Github devs are amazing I'm sure, however it just takes one moment of, "Sheesh, why am I wasting these lines of code when I can consolidate it into one line."
OMFJesus, you people take my blog way too seriously. Of course I understand the issues you all raised, but this is a story (and not even a 100% accurate story because the jackass I work with would find out).
22 comments
[ 2.6 ms ] story [ 8.8 ms ] threadGithub's rails bug really had nothing to do with Git itself.
The fact that Git is a DVCS has nothing to do with the fact that the Rails developers failed to fix a bug on their platform (Rails), which the service that you happen to use to host Git (GitHub) happens to use as well.
Sure, you could use this as an argument to switch to another Git hosting solution (BitBucket, self-hosted), but this could just as easily have happened with a SVN host using Rails....
Also, statements like "Listen, Github is how software is done right now" are just screaming for unnecessary confrontation and useless sideline arguments. I agree that Git is more effective (for most use cases) than any centralized VCS I've seen, but turning that opinion into a bald assertion is just going to cause arguments you really shouldn't be having.
That's exactly my point. The article seems to be confusing a concern about Github for a concern about Git and then spends most of its time addressing the latter. I can (and do!) use Git without using Github. If my organization decides that Github is too much of a risk, that doesn't necessarily mean we'll be dropping Git.
He asked with a sort of cocky, corporate assumption that I too was as appalled as he was at the blantant disregard for security [...] it was clear from the way he was talking about version control that he longed for the days of centralized control where one guy had to manually merge in everyone’s changesets
There is a gigantic gulf between being appalled at github's security and wanting to go back to the days one guy was merging all changes by hand.
it wouldn’t be tough to convince some manager-type that this Github thing does deserve a second-look.
Maybe thats because it is worth taking a second look? Who's going to be convinced by a laundry list that boils down to "shit happens, luckily nothing bad happened this one time and it could never be completely catastrophic"? Thats a incredibly low bar to set. I love github, its well tailored to be a host for an open-source master, but not for private stuff; even if we were willing to host internal services outside the trusted network, I certainly couldn't trust github.
Bottom line is "someone will probably see the exploit" is a gambler's approach to security.
This entire article is based on the false dichotomy that either we use get along with github as it is or go back to svn.
Given the number of projects which directly pull code from github and execute it on production machines, it is not unreasonable to expect basic security from a hosting provider. I don't see why github should be given a second chance.
Sure, there may be others we haven't heard of, but that's potentially true about any service.
"GitHub is a DVCS". Is the author aware that GitHub is... just Git... and that people can host their own Git repos manually? (Or their own mini-GitHub clone gitlab?)
Your product is only as good as the people who build it. Github devs are amazing I'm sure, however it just takes one moment of, "Sheesh, why am I wasting these lines of code when I can consolidate it into one line."