There's a precise reason why I did so called "full disclosure" I started writing an email to security@37singals, then i checked out the previous conversation we had, where i was asked about my link for Hall of Fame. I gave the link and after a month it wasn't added. No, i don't really care, but given some other details (it was the second RJS bug in basecamp, "RJS bug" overall wasn't 0 day at all, your ultimate rejection of RJS removal) i somehow ended up writing a post with full disclosure.
I *mostly* follow responsible disclosure policies. But this is not my duty. Especially when i have couple of reasons to follow other policy. On Monday, December 2, 2013 11:01:21 PM UTC+7, DHH wrote: > > What email is that? I replied to Homakov on Twitter thanking him for the > discovery and stating a clear intent to get the issue resolved. What I > rejected outright was the knee-jerk reaction to remove the possibility of > generating JS responses from Rails. This rejection was confirmed when it > got clear that the motivation behind that specific mitigation strategy was > also motivated by architectural opinions on what's dinosaur and what's not. > > But again, even having this discussion here or on Twitter simply isn't the > proper forum to discuss 0-day exploits. It's the reason we have a > standardized security reporting and response protocol. It's why we go to > great lengths to coordinate proper fixes across multiple versions of Rails, > following the CVE process, and other responsible steps in the process. > > To sidestep all that doesn't help anyone but Homakov in the short-term to > build a reputation as a take-no-prisoners grey hatter. I question the > business strategy of that long-term (imagine having a business dispute with > Homakov after giving him access to your system -- yikes!). > > Again, my opinion of the process is removed from the value of finding > security holes. Of course finding and responsibly disclosing security holes > is a good thing. I just wish that Homakov, and others who might be inspired > by his tactics, would realize that there's plenty of gain to be had > personally by subscribing to these time-tested practices. > > > On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas > <[email protected]<javascript:>> > wrote: > > > David, first I must say I admire both you and Homakov and I'd certainly > hire him if I could afford it. > > > > I believe what led him to create that post was exactly your reponse to > his e-mail. > > > > I agree he shouldn't have created this discussion publicly but you > shouldn't have replied the way you did either. You should instead try to > understand the problem first before saying it would go nowhere. > > > > I believe this is what caused Homakov reaction. > > > > Sincerely, > > Rodrigo. > > > > Em 02-12-2013 13:47, DHH escreveu: > >> Please stop conflating the discovery of a security issue with the > philosophical waxing about architecture. It's not helping the case. As > stated previously, responding with JS is not only a wonderful architectural > pattern, it's also not going anywhere. Not in a gem, not in a deprecation, > not anywhere. We'll fix the security issue, and Rails will continue to > proudly champion the use of this great pattern. > >> > >> Guess what, it won't be the last security issue Rails ever has. Just > like it won't be the last security issue any piece of software ever has. > But we need to level up as a community in our handling of these issues. > >> > >> Frankly, I'm surprised that people are willing to hire Homakov for any > work in the area given his reputation for irresponsible disclosure. Finding > a legit security issues is a great services, but disregarding all security > issue management protocols in their publication is doing a disservice to > all who would otherwise benefit from the work. > >> > >> Rails has had a codified security process for many years now. It's > available for all to read on http://rubyonrails.org/security. Making a > blog post on your personal site isn't one of the channels listed as a > responsible way of disclosing discoveries. Posting specific 0-day attack > vectors against affected sites is not one either. > >> > >> Making a public report over a holiday weekend, and then, when the > response to the report doesn't immediately follow the proposed solution > (remove the feature), go off the reservation with specific attacks is just > plain irresponsible. No two ways about it. It also goes to undermine any > other recommendations or suggestions coming from said reporter. > >> > >> So. Damage is already done for this issue. But lest it encourages > others to act as irresponsibly as Homakov has done of this issue, I hope > others take a broader approach for future issues. Report systemic or > framework issues per the reporting instructions on > http://rubyonrails.org/security. Report specific application issues > directly to application developers responsibly per their reporting > instructions (see https://37signals.com/security-response for the one we > use at 37signals). > >> > >> Presumably we're all in the same boat here: Make Rails better and more > secure. Let's row like we mean that. The Rails security team (Michael > Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past > to provide us with a good process, they've followed that process, and they > deserve our thanks and support. > >> -- > >> You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Core" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > >> To post to this group, send email to > >> [email protected]<javascript:>. > > >> Visit this group at http://groups.google.com/group/rubyonrails-core. > >> For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > You received this message because you are subscribed to a topic in the > Google Groups "Ruby on Rails: Core" group. > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/rubyonrails-core/rwzM8MKJbKU/unsubscribe. > > > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > > To post to this group, send email to > > [email protected]<javascript:>. > > > Visit this group at http://groups.google.com/group/rubyonrails-core. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
