Hacker News Reader

Comment by chrisacky | Hacker News Reader

This is a shocking portrayal of the actual occurrences.

They/He make it sound like they were proactive about all of this, always one step ahead of the attacker/@homokov

> As soon as we detected the attack we expunged the unauthorized key and suspended the user.

They didn't detect anything. They were informed. It also wasn't an attack. If it was an attack, you wouldn't have seen it coming, or in the very least more damage would have been done.

As far as attacks go, this was probably the "whitest" of white that has ever gone down. Not only did the "attacker" not do any actual damage, but he was continually ignored.

This is a shameful handling of the actual events.

View on HN

Saw your full comment on github: https://github.com/blog/1068-public-key-security-vulnerabili... Well put. I guess startups can act enterprisy too when money is involved. The irony is that had they been actually proactive, they would have avoided this kind of publicity and money (for 3rd party audits).

I just wrote a longer than expected summary.

http://news.ycombinator.com/item?id=3664400

I agree with your sentiments. What Homokov did was childish, but he made his point in a non-malicious way that got the message out better than silently writing a letter to the admins. It is evident from the events that occurred that this is an issue in Rails that needs to be fixed. What does it say about a feature of your framework when, by default, one of the largest code repository hosting sites in the world is vulnerable? The phrase "meaningful defaults" has never been more relevant.

I, too, agree with your sentiments. But I wish people would lay off of GitHub. The were mostly just a bystander here.

The real troublemakers are the Rails developers who seem to seriously believe that leaving such subtle security traps in their framework (and then blaming the developers who follow the example code) is a defensible position.

I disagree. Github is very much not the bystander here. They chose to use Rails (which is fine). But GH then has the onus to properly deploy their app.

An analogy would be a door that only locks with a special key in a certain sequence. IF you choose not to do so, it's merely a door. Obviously, you could argue that that's a bad default but I think that goes to the crux of the problem.

I'm an experienced developer, but not terribly familiar with Rails.

What do you mean "properly deploy their app"?

The sample code at rubyonrails.org looks like it has the same problem to me, i.e., it would be vulnerable if it were put into production in the right (entirely reasonable) circumstances.

> What do you mean "properly deploy their app"?

No matter how bad the tool actually is, only a terrible craftsman blames his tools. That's what he meant.

Both Rails and GH are at fault. Rails for not discouraging poor practices and GH for not being more familiar with their own stack.

Reply on news.ycombinator.com