Obviously this situation is a bit more complicated, as a ticket was opened up, and a lot of community discussion occurred. In general, emails to the security list are taken extremely seriously.
Where would one find that link? The link to "Bugs/Patches" on rubyonrails.org links directly to the GitHub issue tracker. A search on Google for "link:rubyonrails.org/security" finds only a single reference, and it is from someone evaluating how other vendors handle security issues. (My guess: it used to be linked, but then Rails moved to GitHub, and some intermediate landing page was lost in the shuffle.)
OK, here's a specific mistake made by a rails committer in handling this issue. drogus closed [this issue](https://github.com/rails/rails/issues/5239) without bothering to tell GitHub about it. This meant that fewer people saw it, and fewer people had a chance to tell GitHub about it. (One even thought of telling them about it, but unfortunately suggested that someone else do it instead of actually doing it.)
I think that perhaps the Rails team should have someone reviewing that issues were properly handled.
I would expect the guy who found an issue with GitHub to report it to them. Yes, the rails people could have, should have.. But they explicitly asked "him" to report and there is no word on whether he did it or not.
You're stating the obvious. Egor Homakov should have done a lot of things differently. But there is little that can be done about the behavior of bad actors in the rails community. With people on the team, it's different. Practices can be audited, mistakes can be pointed out, and the fine people in the Rails team can respond to criticism and improve their performance.
People are reading this as a vulnerability in rails when it is actually a vulnerability in GH's code. Your comment unfortunately is going to add to it :(.
What should he have reported to rails security team? Shouldn't he have been contacting GH security team instead?
The problem with this is that the getting started guide[0] uses this 'mass assignment' method in one of the examples (under section 6.8) without any mention of a caveat. The scaffolding does likewise.
You'd be forgiven for thinking there was no vulnerability, given the lack of warning over that sort of code, and the fact that Rails does a lot of 'magic' behind the scenes (especially since you're using their own helper classes to handle form input and such like).
When I read "this vulnerability affects tons of Rails apps," I read that as a security vulnerability in Rails. I'm not a user of the framework, but I've heard "convention over configuration" often enough to think that if this was brought up in the Rails issues tracker, it should be prevented by convention.
If an app makes it possible to do SQL injections, whose fault is it?
What Rails have done is to have a particular default (whose correctness can be debated) and document how it can be exploited and how to safeguard from it.
You didn't really answer my question. Rails has all the helpers in place to sanitize input for SQL injection. Why in that case do they apply the defaults and not do so in this case? They both amount to making unwanted DB modifications.
The Rails Guides may discuss it, but this does not excuse the fact that for years the Rails core team knowingly shipped code (and generators that created) insecure by default code.
No, this isn't a "Rails vulnerability" in the traditional sense, but the level of immaturity and groupthink in the response to these issues being reported is staggering and somewhat shameful.
(1) it has seemingly embarrassed some rails committers into taking this seriously, whereas they dismissed the issue before;
(2) I bet there were at least 20 devs who saw this on HN, said fuck my life, and hopped on their vpn to check if their site is vulnerable.
No drama disclosures didn't accomplish either of these things. Hopefully github won't take it too personally, and Egor was actually (as he seemed!) careful not to break anything.
(And I am not being a hater here, I am also using Rails for some hobby projects & had to double check all my code. I somehow didn't even think about foreign keys in mass assignment... sigh.)
Obviously this situation is a bit more complicated, as a ticket was opened up, and a lot of community discussion occurred. In general, emails to the security list are taken extremely seriously.