On Monday, February 11, 2013 at 4:19 PM, Justin Hart wrote:
Were the ActiveRecord changes included in the GitHub diff intended to be released? The Changelog says 'unreleased'. It looks like its in reference to a note on the Security list: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/ZOdH5GH5jCUI support the changes, just wondering if it was unintended since it wasn't mentioned in the OP.
--
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 rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
On Tuesday, 12 February 2013 at 3:28 PM, James Harton wrote:
This[1] caused a bunch of our specs to fail (on 3.1.11), and due to the fact that they're not immediately related to the critical security fixes we're trying to deploy today we decided to revert them on our fork instead. Forgive me if I'm wrong, but it would seem unwise to me to include unrelated behaviour changes in a patch that is supposed to contain only one security fix?
I'm surprised that it was included after the earlier security advisory about this issue said only Rails 4 would get chances to mitigate it. Did the risk assessment get worse or is it just doing whatever we can to improve the situation?
Future releases of Rails will contain changes to mitigate the risk of
this class of vulnerability, however as long as this feature is still
supported this risk will remain.
I've posted my 2c on the corresponding pull request, https://github.com/rails/rails/pull/9207. Doesn't feel like a safe approach to me, and it's broken basic join conditions when there's table aliasing.