Sorry, I meant Zack. --
Maurizio De Santis 2013/12/3 Maurizio De Santis <[email protected]> > Marius, your solution is not much different from responding a render :json > : you send only the data, and the processing code is already on client > side; transponder.js seems to me that it adds an abstraction level in order > to manage the data, but it is different from RJS, which sends the execution > code too, that is necessary for running the examples made before, like > Disqus, or single page apps. > > transponder.js a good solution if you don't want / need to send the > execution code, as render :json , but I think I got that RJS is necessary > for other contexts. > > -- > > Maurizio De Santis > > > 2013/12/2 Marius Corîci <[email protected]> > >> I much appreciate RoR, its community Homakov included. I never saw RoR >> security team at least one time to appreciate Homakov's findings. Perhaps >> you should take it closer by first recognize his security work over RoR. >> I'm quite sure that Homakov would have comply to your rules in the end. >> >> >> On Monday, December 2, 2013 5:47:07 PM UTC+2, DHH wrote: >>> >>> 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 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]. >> 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. >> > > -- 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.
