5. You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, or access to the Service without the express written permission by GitHub.
You do something dumb like this, you should live with the consequences. In legal terms, if they don't enforce their TOS, it can be a legal issue later.
I love how he punts on the terms with "but lets get real".
Analogy: You break into a house and get caught. "Oh yeah, laws. But lets get real, I was pointing out they didn't lock their door."
Then, he reopened the bug to prove it was a bug, and they closed it again.
Then, he submitted a new bug, 1001 years in the future, and they closed it, saying "Good one ;)"
Then, he committed a text document to master, and they got all upset about it and got Github staff involved.
How about this Ruby devs: actually consider what you're saying. Isn't the point of Ruby to make things simple? Yet, somehow, making rational default choices only applies to everything but this. I know that you love to feel better than everyone else (see: http://37signals.com/svn/posts/3124-give-it-five-minutes), but seriously, you shouldn't get all upset about it later when it turns out you're wrong.
This is why I refuse to learn Ruby. I don't want to be associated with that community. "Learn Ruby if you want to be associated with a bunch of people who call themselves Rockstar Programmers."
A common thread here seems to be grouping Github and Rails.
Its interesting how bring up their Terms Of Service gets discounted and the holy war just takes over. No where did I mention Rails, Ruby, community, or anything else.
Me: He broke the rules. Retort: I like plant.
Disclaimer: The actions of individuals are representative of individuals. Drawing dramatic generalizations accomplishes nothing. Yes, there are more vocal asses in every community. For every asshat there is likely 100 quiet people. Right now, I'm being an asshat.
Gee, homakov is Russian. All Russians must want to hack your site. Really? No, its a dumb generalization.
* Not actually DHH.
You refuse to learn a language due to how a project acts? Have you ever read the {open,free,net}BSD or Linux mailing lists? You're not going to make it far in software development with an attitude like that.
Unless a quantum computing breakthrough alters the way we control computers, there will never be a one-language to rule them all. We'll continue having a wide diaspora and will take evolutionary steps to bind ideas together. Preemptive and comprehensive security model might be just one of those ideas.
Ruby is a really cool language with some fascinating features--don't limit yourself by assuming that you also have to learn the Rails stuff.
Seriously, give it a shot in one of its more palatable forms.
If you come from PHP or Java anyway.
no new genuinely new programming ideas have happened since the 70s and 80s.
Don't be obtuse.
Don't get me wrong, though. I can see being turned off by rockstars, but you've found a language unencumbered by them?
Example:
XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper (h), which you could use to escape content that you knew to be vulnerable.
Unfortunately, many Rails users did not use this feature in all places they should have used it. As a result, many applications (Twitter included) suffered from whack-a-mole XSS vulnerabilities.
We were unable to solve this problem in the 2.x branch, because automatically escaping all text being put onto the page would be a massive breaking change and would break every app in existence.
Further, simply escaping all text would not really solve the problem. For example, the "<form>" tag generated by Rails itself should not be escaped, while any of its contents or attributes provided by the application should. Asking the user to take on the responsibility to mark Rails-generated content as not needing escaping would reintroduce the same problem we had before: people would "unescape" things too eagerly, and apps would tend to have vulnerabilities.
The solution was to release a plugin for Rails 2.3 users (rails_xss) and change the default in Rails 3. It isn't perfect: there are still cases where applications have to mark strings as "safe", and applications that have to do so often might have the same problem, but I think we did a good job, all things considered.
This case is quite similar. Rails provides all the tools necessary to have a secure application (attr_accessible is the equivalent of h), but many apps don't use it correctly (or at all). In short, a Rails security default seems to be wrong, insofar as "wrong" means that many people fail to use the security feature, causing their applications to be vulnerable.
As with the XSS feature, fixing this problem requires some thought. Simply changing the default would break a lot of applications in the wild. Like XSS, it's probably correct to do so anyway here. However, like XSS, we should make sure that we have done everything we possibly can to mitigate the additional cost associated with complying with the new default. If it's too painful, many people will overeagerly bypass the feature, reintroducing the very issue we were trying to protect them from.
In this case, I have proposed a solution that I think will mitigate a lot of the problem (https://gist.github.com/1974187), and we will likely ship it as a Rails 3.2 plugin. This will allow us to gather feedback about unexpected consequences and ensure that when we change the default for Rails 4 (which has not even shipped a prerelease yet), it actually mitigates the security problem in the vast majority of Rails applications.
Saying "we'll provide the tools and insist that developers use them safely and securely" is a bullshit answer, and always has been.
You're either secure by default, or not at all. In this case, not at all.
I hope this marks a turning point in the way the Rails team think about security.
ps At least Rails no longer allows web crawlers to delete resources by issuing GET requests.
I'd rather have the model and the ORM be pulled apart and the model make this distinction.
Or create another class that knows how to safely pull values out of a params list and use it to create a model.
But it's bad enough that the controllers "look" like they belong to a model in default Rails generators. This creates a certain amount of laxity in programmer's thinking. It boxes their thinking in instead of letting their thinking go free.
Thanks again for your hard work and being a public voice on the issue.
More seriously, just because he violated the ToS doesn't mean that they have to be dicks.
From all appearances, GH is taking it quite seriously. Because it is a serious matter. Egor on the other hand wasn't taking it seriously.
This isn't a 0-day vulnerability--this is an issue known to the rails devs, and one which they decided wrongly on. Sometimes you've got to take things to the next level of visibility.
Whether or not rails' defaults are sane is a completely separate question. Egor acted out against GH when he was ignored by rails dev. Two entirely different parties.
For a normal project, sure, whatever, but when the security hole is in a framework--especially one as widely deployed as rails--you eventually must cede that, yeah, the fastest way to get something serious fixed is to do a public exploit.
What if he'd submitted the fix to github and they'd quietly patched it and said nothing? What if they'd said something but nobody cared because hey, it's fixed now? What if they'd flat-out ignored it as the rails devs did (perhaps even citing that as their reason)?
No, security only reliably gets addressed when it hurts and hurts publicly.
The combination of hitting the exploit on perhaps the most visible site for the target audience and doing so in a way that didn't harm anything is impressive.
100% agree here. The Rails devs may have ignored his issue, but GitHub are the victims here. Why not email GitHub and inform them, on the provision they communicate the fix they just made?
Doing this and saying "P.S. GH sorry, I was bored" is not acceptable.
And yet, people have stopped using C for a lot of things because of the security implications...
Look, when Rails is pushed as an out-of-the-box magic web stack--and it is--, and the out-of-the-box config has these problems available--which seems to be the case--maybe there is something to be said for the framework needing fixing.
Just because I can write code that prevents various exploits does not mean I expect the rest of the world to--and I sure as hell don't do so while brandishing about how even beginners can use my tools.
It's not even being "rewarded"--it's being "not punished".
Wouldn't you like to have people spot vulnerabilities on your site and report them promptly without also breaking things? Seems a little ungrateful, yeah?
If we are all going to migrate to the cloud and assume our services (no longer under our control) are handled competently, we must place a higher premium on vetting that competency.
Yes. I'd even send him a thank-you email, and add him to our list of contributors.
I'd then of course contact the customer (probably over phone, as quickly as possible), explain the vulnerability, explain what happened, and explain how we were fixing it. Then I'd write a post about it, and put it on the front of the site.
That's how you do business.
Like that?
"Dear Grabastic,
Today we had a demonstration by a user (xxx) of a security vulnerability on our site.
${VULNERABILITY_EXPLANATION}
We believe that it is possible that your application or records are covered in the scope of the exploit, because of the fact that ${VULNERABILITY_APPLICATION}.
In order to fix this issue, we have ${VULNERABILITY_PATCH}.
We have thanked this user for their vigilance in spotting bugs and security weaknesses in our site, and they have been added to our contributors-security page here (link).
We have a stance that security is something that can only be improved by lots of inquisitive eyes, and so if you have seen any issues that concern you, please do not hesitate to inform us and/or demonstrate the vulnerability--provided, of course, you do so without breaking anything permanently. :)
Our service is better today than it was yesterday, and we hope that with the patience and openness of our users it will be still better tommorrow!
Sincerely, angersock "
See, not so hard!
+another showcase of rails apps vunlerability. 2 +Github pwned. again :( 3 +will you pay me for security audit?
It kinda sounds like you've succumbed to an extortion demand.
(http://homakov.blogspot.com/2012/03/im-disappoint-github.htm...)
If this is true, would you please consider unsuspending him? This doesn't seem like a good way to reward this sort of behavior (i.e., helping through hacking).