GitHub Impervious to Super Missiles

Right after Github got nailed with that mass assignment vulnerability in Rails, one of my colleagues asked me when I thought everyone would start to abandon Github. He asked with a sort of cocky, corporate assumption that I too was as appalled as he was at the blantant disregard for security. His unspoken subtext was “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”.

Little did this guy know that it was I who created the first corporate Github repository for this particular organization in an act of rogue VCS activism. And, 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. I remember that sort of work, it was awful. Tack on a couple of days to the development cycle to deal with awful SVN conflict markers.

I didn’t respond. Honestly, if you depend on Github at work, you are in an odd spot, you are hoping that a co-worker doesn’t have an axe to grind against the service because it wouldn’t be tough to convince some manager-type that this Github thing does deserve a second-look. I did prepare a list of reasons why this particular GitHub vulnerability doesn’t matter… Here it is, you might need it yourself:

  1. Github was hacked, by a friendly. A bored Russian named Homakov was just trying to make a point about Rails security. Github initially suspended his account, but has since reinstated it. It isn’t like Github has hijacked by ransom-demanding Sudanese pirates here.
  2. When they found out about the problem, they fixed it… immediately. They didn’t try to hide it, they responded just the way any hosted provider should.
  3. They made the right decision and had everyone reconfirm the identity of every key ever uploaded to Github. You couldn’t ask for a better response. They very much could have taken some lazy road and just ignored the possibility the every key could have been compromised.
  4. Go ahead take all the code you want, the house is locked. Even if our code was transfered to a hostile (which it likely wasn’t), you don’t get into production without a secret, and those secrets are not in code.
  5. 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.
  6. Ask any of the developers what they prefer, using Github or using the old proprietary system. Ask them how much time they used to waste merging branches.
  7. Github is a DVCS, every single developer had a full copy of the repository checked out, if someone had compromised code it would be apparent.
  8. Listen, Github is how software is done right now, you move back to some proprietary POS, and I guarantee you half of the developers will just take all the vacation they are due and tender resignations.
  9. Github is Impervious to Super Missiles, please just go back to management.
  • http://chillenious.wordpress.com/ Eelco

    pesky manager types… :-)

  • http://twitter.com/soulnafein David Santoro (@soulnafein)

    Let me add a point. Github is just a repository, you can use Git without Github. And if you really want it to run in your corparate network, then you should use Github Enterprise -> https://enterprise.github.com/

  • anon-coward

    Github rocks, Tim, but you and I (and no doubt paying Github users) are crossing their fingers that the “friendly Russian” was the first hacker to stumble on this gaping security hole.

  • http://twitter.com/hanseldunlop Hansel Dunlop (@hanseldunlop)

    It’s like when kernel.org was hacked. There was a load of press about how the Linux kernel had been compromised.

    All by people who don’t understand what happens when you type git diff.