Live data from Hacker News

GitHub and Rails: You have let us all down.

chrisacky.posterous.com

41–50 of 205 posts

Re: GitHub and Rails: You have let us all down.

#41

Earlier quoted context omitted.

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…

Did he notify github directly, or did he notify the rails team in a github-issue in the rails project? 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…

It's sort of a sticky situation. My take on it wasn't that this was so much to screw with GitHub as it was to show the Rails team the true severity of an issue they downplayed. It gets a bit circuitous because Rails is hosted on GitHub and GitHub is a Rails app. Had he reported it to GitHub and they patched it, which is arguably the proper thing to have done, nothing would have happened on the Rails side of the equation. All told, I think he did the right thing.

Re: GitHub and Rails: You have let us all down.

#42
post #23

Earlier quoted context omitted.

I agree wholeheartedly. I always facepalm when people aren't able to work because the internet is down (read: no github access). Just start an SSH server, netcat some keys around (or use an USB stick), and get back to work again :) 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…

While GitHub's uptime has improved immensely, it was a serious problem. It's not as simple as pushing your repo someplace else when you use submodules. If anyone has a fix for that I'd love to hear it. I've ceased using submodules in most cases precisely because GitHub used to go down so frequently, but now I have the same problem with anything that's a :git entry in my Gemfile.

One workaround for submodules would be local DNS entries, i.e. edit /etc/hosts to make github.com the temporary local github.com. Also, I generally mirror submodule repos and use those. But neither of these "solutions" fixes the actual issue of course. Not using submodules sounds like the best solution to me :)

Re: GitHub and Rails: You have let us all down.

#43
post #21
post #19

Earlier quoted context omitted.

I lost a tremendous amount of respect for Github when I heard they'd suspended his account. 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.

Why? I would expect any company to suspend the account of someone hacking them.

I would expect any company to do far more than suspend the account, especially knowing exactly who did it.

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

Re: GitHub and Rails: You have let us all down.

#44
post #7

I fail to see what GitHub did wrong here. They were attacked, they suspended the account doing the hacking, and they fixed the problem. Then, they blogged about it, explaining in detail what happened. Apparently they weren't quite reverent enough for the person who wrote this article.

Egor is a human whose motivations were totally obvious and whose actions were transparently harmless (and, in fact, net helpful.) The Github team are behaving foolishly if they can't or won't distinguish that from an "attack."

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.

Re: GitHub and Rails: You have let us all down.

#45
post #25

"If you are one of those strange coders that don't use GitHub". Never used and never will. What's strange with that?

That comment jumped out at me as well. I use Perforce at work and run my own at home. Both with local and offsite redundancy. I guess that makes me strange.

Re: GitHub and Rails: You have let us all down.

#46
post #25

"If you are one of those strange coders that don't use GitHub". Never used and never will. What's strange with that?

"If you are one of those strange coders that don't use GitHub and think you are in the clear because you use SVN/Mercurial"

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.

Re: GitHub and Rails: You have let us all down.

#47

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.

Re: GitHub and Rails: You have let us all down.

#48

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…

I have to agree that suspending the account was dumb as if he wanted to be malicious, he'd have created dummy accounts and would have committed malicious code to popular projects.

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?

Re: GitHub and Rails: You have let us all down.

#49

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 is a perfect summary and exactly the sentiments that I couldn't express in the article. I've quoted you with attribution if you are okay with that?

Re: GitHub and Rails: You have let us all down.

#50
post #38
post #30

Earlier quoted context omitted.

LANs are broken. Why is it that we have usable tools for connecting halfway round the world, but find it massively hard to coordinate ourselves across a small office when the internet is down. It is total madness.

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.
Post reply on HN