Log message:
www/ruby-rails61: update to 6.1.3.2
Real changes are in www/ruby-actionpack61 only.
## Rails 6.1.3.2 (May 05, 2021) ##
* Prevent open redirects by correctly escaping the host allow list
CVE-2021-22903
* Prevent catastrophic backtracking during mime parsing
CVE-2021-22902
* Prevent regex DoS in HTTP token authentication
CVE-2021-22904
* Prevent string polymorphic route arguments.
`url_for` supports building polymorphic URLs via an array
of arguments (usually symbols and records). If a developer passes a
user input array, strings can result in unwanted route helper calls.
CVE-2021-22885
*Gannon McGibbon*
|
Log message:
www/ruby-rails61: update to 6.1.3
Rails 6.1.3 (February 17, 2021)
[ActionPack]
* Re-define routes when not set correctly via inheritance.
*John Hawthorn*
[ActiveRecord]
* Fix the MySQL adapter to always set the right collation and charset
to the connection session.
*Rafael Mendonça França*
* Fix MySQL adapter handling of time objects when prepared statements
are enabled.
*Rafael Mendonça França*
* Fix scoping in enum fields using conditions that would generate
an IN clause.
*Ryuta Kamizono*
* Skip optimised #exist? query when #include? is called on a relation
with a having clause
Relations that have aliased select values AND a having clause that
references an aliased select value would generate an error when
#include? was called, due to an optimisation that would generate
call #exists? on the relation instead, which effectively alters
the select values of the query (and thus removes the aliased select
values), but leaves the having clause intact. Because the having
clause is then referencing an aliased column that is no longer
present in the simplified query, an ActiveRecord::InvalidStatement
error was raised.
An sample query affected by this problem:
Author.select('COUNT(*) as total_posts', 'authors.*')
.joins(:posts)
.group(:id)
.having('total_posts > 2')
.include?(Author.first)
This change adds an addition check to the condition that skips the
simplified #exists? query, which simply checks for the presence of
a having clause.
Fixes #41417
*Michael Smart*
* Increment postgres prepared statement counter before making a
prepared statement, so if the statement is aborted without Rails
knowledge (e.g., if app gets kill -9d during long-running query or
due to Rack::Timeout), app won't end up in perpetual crash state for
being inconsistent with Postgres.
*wbharding*, *Martin Tepper*
|