I think there was a third and better way for Homakov to "solve" the problem:
He should fill some CVE reports. It will give the same shame to programmers, some more time to fix vulnerabilities to site owners, but also it give an additional pressure to programmers from all CVE subscribers.
Posted Mar 8, 2012 17:51 UTC (Thu) by nix (subscriber, #2304)
[Link]
It will give the same shame to programmers
Really? This made the tech news all over the place. Another CVE would just elicit a sigh: there are many thousands of them.
GitHub incidents spawns Rails security debate
Posted Mar 8, 2012 21:47 UTC (Thu) by bronson (subscriber, #4806)
[Link]
This bug would never merit a CVE. The reply would be something like, "If you don't want to get pwned, just whitelist your params like the docs have said since 2008. Duh."
The value in what Homakov did was demonstrating that even extremely competent, experienced Rails developers don't always follow the docs. I'm not sure how anyone could do that without actually showing it in the wild.
GitHub incidents spawns Rails security debate
Posted Mar 15, 2012 15:07 UTC (Thu) by rqosa (subscriber, #24136)
[Link]
> This bug would never merit a CVE.
Do you mean the Rails default behavior, or the GitHub vulnerability? It seems like the GitHub vulnerability would have merited a CVE — if it weren't for the GitHub software being purely in-house (not distributed outside of GitHub, Inc.), correct?
GitHub incidents spawns Rails security debate
Posted Mar 26, 2012 20:29 UTC (Mon) by bronson (subscriber, #4806)
[Link]
It's true, Github Enterprise Install might merit a CVE. I don't think that the Rails default behavior (documented since 2008?) or Github (as you say, not distributed) would warrant one.
But, while I've done a fair amount of Rails, I'm not the most in touch with CVEs.