Re: ports/168524: port www/redmine is incorrectly marked as broken
Synopsis: port www/redmine is incorrectly marked as broken Responsible-Changed-From-To: freebsd-ports-bugs->ruby Responsible-Changed-By: edwin Responsible-Changed-When: Fri Jun 1 14:31:29 UTC 2012 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=168524 ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: ports/168435: x11/ruby-gnome2 update to 1.1.3
Synopsis: x11/ruby-gnome2 update to 1.1.3 Responsible-Changed-From-To: freebsd-ports-bugs->ruby Responsible-Changed-By: edwin Responsible-Changed-When: Fri Jun 1 19:40:13 UTC 2012 Responsible-Changed-Why: Over to maintainer (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=168435 ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Ruby 1.9 as default
Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. I would like to get feedback on this idea. If you have experience with Ruby 1.9 as default, good or bad, please speak up. You can test this by setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf or editing Mk/bsd.ruby.mk and setting the same variable there. Thanks, Steve ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Ruby 1.9 as default
On Fri, 01 Jun 2012 21:32:53 -0400 Steve Wills mentioned: > Hi All, > > I think we should try to make Ruby 1.9 the default Ruby again and would > like to see it done before 9.1 is released. I've submitted a patch which > does this and requested and exp-run from portmgr. > > I would like to get feedback on this idea. If you have experience with > Ruby 1.9 as default, good or bad, please speak up. You can test this by > setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf or editing Mk/bsd.ruby.mk > and setting the same variable there. > I'm not sure it's a good idea. Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads and fork. That is fork in ruby 1.9 hangs sometimes... OTOH, I've been running ruby 1.9 as default on both of my desktops and have not seen major problems except this one. Still, it'd be nice for someone to fix it first (I remember there were a lot of eager commiters at the time I gave up my commit bit). The main question is whether the switch to 1.9 will be beneficial for our users. Apart from some libraries targeting 1.9 exclusivly now, most of of them still work with 1.8 and there're still some that work with 1.8 only. Given that most of the ports users mostly care for 3rd party applications to work, I'm not sure if the switch to 1.9 will be a win for them... -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Ruby 1.9 as default
On Jun 1, 2012, at 10:30 PM, Stanislav Sedov wrote: > On Fri, 01 Jun 2012 21:32:53 -0400 > Steve Wills mentioned: > >> Hi All, >> >> I think we should try to make Ruby 1.9 the default Ruby again and would >> like to see it done before 9.1 is released. I've submitted a patch which >> does this and requested and exp-run from portmgr. >> >> I would like to get feedback on this idea. If you have experience with >> Ruby 1.9 as default, good or bad, please speak up. You can test this by >> setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf or editing Mk/bsd.ruby.mk >> and setting the same variable there. >> > > I'm not sure it's a good idea. > Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads and > fork. That is fork in ruby 1.9 hangs sometimes... Could you give me some more info on this? If I can reproduce it perhaps I can track it down and solve it. > OTOH, I've been running ruby 1.9 as default on both of my desktops and have > not seen major problems except this one. Still, it'd be nice for someone > to fix it first (I remember there were a lot of eager commiters at the time > I gave up my commit bit). > > The main question is whether the switch to 1.9 will be beneficial for our > users. Apart from some libraries targeting 1.9 exclusivly now, most of of > them still work with 1.8 and there're still some that work with 1.8 only. > Given that most of the ports users mostly care for 3rd party applications > to work, I'm not sure if the switch to 1.9 will be a win for them... Isn't 1.9 a bit faster than 1.8? And 1.8 doesn't build with clang while 1.9 does, so we'll at least want to switch it before 10.0 comes out, IMHO. Also, 1.9 has been the default version from ruby-lang.org for a long time and the community is making good progress towards moving to 1.9 over all. I think most things work with 1.9 now, but I could be wrong. Are there specific apps that you are thinking of that don't work with 1.9? 1.9 definitely seems to pass all the tests that 1.8 passes and more. As far as what users of ports want, the point of this mail was to get them to speak up and voice their opinions. :) BTW, do you use 1.8 or 1.9? Actually, I'm betting you use Rubinius now that I think about it, no? Steve ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Ruby 1.9 as default
The community is indeed moving to 1.9 and 1.8 is nearing end of life. I have been using 1.9 on FreeBSD for months now without any issues, and I would suggest we switch and try to iron out any remaining issues. Jos ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Fwd: [oss-security] SQL Injection Vulnerability in Ruby on Rails (CVE-2012-2661)
A vulnerability has been found in a port you maintain. Please commit
an update and write up a VuXML report. If you need help feel free to
email ports-secur...@freebsd.org,
-- Forwarded message --
From: Aaron Patterson
Date: 31 May 2012 15:16
Subject: [oss-security] SQL Injection Vulnerability in Ruby on Rails
(CVE-2012-2661)
To: oss-secur...@lists.openwall.com
SQL Injection Vulnerability in Ruby on Rails
There is a SQL injection vulnerability in Active Record, version 3.0
and later. This vulnerability has been assigned the CVE identifier
CVE-2012-2661.
Versions Affected: 3.0.0 and ALL later versions
Not affected: 2.3.14
Fixed Versions: 3.2.4, 3.1.5, 3.0.13
Impact
--
Due to the way Active Record handles nested query parameters, an
attacker can use a specially crafted request to inject some forms of
SQL into your application's SQL queries.
All users running an affected release should upgrade immediately.
Impacted code directly passes request params to the `where` method of
an ActiveRecord class like this:
Post.where(:id => params[:id]).all
An attacker can make a request that causes `params[:id]` to return a
specially crafted hash that will cause the WHERE clause of the SQL
statement to query an arbitrary table with some value.
Releases
The FIXED releases are available at the normal locations.
Workarounds
---
This issue can be mitigated by casting the parameter to an expected
value. For example, change this:
Post.where(:id => params[:id]).all
to this:
Post.where(:id => params[:id].to_s).all
Patches
---
To aid users who aren't able to upgrade immediately we have provided
patches for the two supported release series. They are in git-am
format and consist of a single changeset. We have also provided a
patch for the 3.0 series despite the fact it is unmaintained.
* 3-0-params_sql_injection.patch - Patch for 3.0 series
* 3-1-params_sql_injection.patch - Patch for 3.1 series
* 3-2-params_sql_injection.patch - Patch for 3.2 series
Please note that only the 3.1.x and 3.2.x series are supported at
present. Users of earlier unsupported releases are advised to upgrade
as soon as possible as we cannot guarantee the continued availability
of security fixes for unsupported releases.
Credits
---
Thanks to Ben Murphy for reporting the vulnerability to us, and to
Chad Pyne of thoughtbot for helping us verify the fix.
--
Aaron Patterson
http://tenderlovemaking.com/
--
Eitan Adler
From 99f030934eb8341db333cb6783d0f42bfa57358f Mon Sep 17 00:00:00 2001
From: Aaron Patterson
Date: Wed, 30 May 2012 15:06:12 -0700
Subject: [PATCH] predicate builder should not recurse for determining where
columns. Thanks to Ben Murphy for reporting this
CVE-2012-2661
---
.../active_record/relation/predicate_builder.rb|6 +++---
activerecord/test/cases/relation/where_test.rb | 19 +++
2 files changed, 22 insertions(+), 3 deletions(-)
create mode 100644 activerecord/test/cases/relation/where_test.rb
diff --git a/activerecord/lib/active_record/relation/predicate_builder.rb
b/activerecord/lib/active_record/relation/predicate_builder.rb
index 505c3f4..84e88cf 100644
--- a/activerecord/lib/active_record/relation/predicate_builder.rb
+++ b/activerecord/lib/active_record/relation/predicate_builder.rb
@@ -5,17 +5,17 @@ module ActiveRecord
@engine = engine
end
-def build_from_hash(attributes, default_table)
+def build_from_hash(attributes, default_table, check_column = true)
predicates = attributes.map do |column, value|
table = default_table
if value.is_a?(Hash)
table = Arel::Table.new(column, :engine => @engine)
- build_from_hash(value, table)
+ build_from_hash(value, table, false)
else
column = column.to_s
- if column.include?('.')
+ if check_column && column.include?('.')
table_name, column = column.split('.', 2)
table = Arel::Table.new(table_name, :engine => @engine)
end
diff --git a/activerecord/test/cases/relation/where_test.rb
b/activerecord/test/cases/relation/where_test.rb
new file mode 100644
index 000..90c690e
--- /dev/null
+++ b/activerecord/test/cases/relation/where_test.rb
@@ -0,0 +1,19 @@
+require "cases/helper"
+require 'models/post'
+
+module ActiveRecord
+ class WhereTest < ActiveRecord::TestCase
+fixtures :posts
+
+def test_where_error
+ assert_raises(ActiveRecord::StatementInvalid) do
+Post.where(:id => { 'posts.author_id' => 10 }).first
+ end
+end
+
+def test_where_with_table_name
+ post = Post.first
+ assert_equal post, Post.where(:posts => { 'id' => post.id }).first
+end
+ end
+end
--
1.7.5.4
From b71d4ab9d7d61ebe3411a8754e9fe93d3587704e Mon Sep 17 00:00:00 2001
From: Aaron Patterson
Date: Wed, 30 May 2012 15:05:19 -0700
Subject: [PATCH] predicate builder should not recurse for determining where
Fwd: [oss-security] Unsafe Query Generation Risk in Ruby on Rails (CVE-2012-2660)
A vulnerability has been found in a port you maintain. Please commit
an update and write up a VuXML report. If you need help feel free to
email ports-secur...@freebsd.org,
-- Forwarded message --
From: Aaron Patterson
Date: 31 May 2012 15:15
Subject: [oss-security] Unsafe Query Generation Risk in Ruby on Rails
(CVE-2012-2660)
To: oss-secur...@lists.openwall.com
Unsafe Query Generation Risk in Ruby on Rails
There is a vulnerability when Active Record is used in conjunction
with parameter parsing from Rack via Action Pack. This vulnerability
has been assigned the CVE identifier CVE-2012-2660.
Versions Affected: ALL versions
Not affected: NONE
Fixed Versions: 3.2.4, 3.1.5, 3.0.13
Impact
--
Due to the way Active Record interprets parameters in combination with
the way that Rack parses query parameters, it is possible for an
attacker to issue unexpected database queries with "IS NULL" where
clauses. This issue does *not* let an attacker insert arbitrary
values into an SQL query, however they can cause the query to check
for NULL where most users wouldn't expect it.
For example, a system has password reset with token functionality:
unless params[:token].nil?
user = User.find_by_token(params[:token])
user.reset_password!
end
An attacker can craft a request such that `params[:token]` will return
`[nil]`. The `[nil]` value will bypass the test for nil, but will
still add an "IS NULL" clause to the SQL query.
All users running an affected release should either upgrade or use one
of the work arounds immediately.
Releases
The FIXED releases are available at the normal locations.
Workarounds
---
This problem can be mitigated by testing for `[nil]`. For example:
unless params[:token].nil? || params[:token] == [nil]
user = User.find_by_token(params[:token])
user.reset_password!
end
Another possible workaround is to cast to a known type and test
against that type. For example:
unless params[:token].to_s.empty?
user = User.find_by_token(params[:token])
user.reset_password!
end
Patches
---
To aid users who aren't able to upgrade immediately we have provided
patches for the two supported release series. They are in git-am
format and consist of a single changeset.
* 3-0-null_param.patch - Patch for 3.0 series
* 3-1-null_param.patch - Patch for 3.1 series
* 3-2-null_param.patch - Patch for 3.2 series
Please note that only the 3.1.x and 3.2.x series are supported at
present. Users of earlier unsupported releases are advised to upgrade
as soon as possible as we cannot guarantee the continued availability
of security fixes for unsupported releases.
Credits
---
Thanks to Ben Murphy for reporting the vulnerability to us, and to
Chad Pyne of thoughtbot for helping us verify the fix.
--
Aaron Patterson
http://tenderlovemaking.com/
--
Eitan Adler
From c202638225519b5e1a03ebe523b109c948fb0e52 Mon Sep 17 00:00:00 2001
From: Aaron Patterson
Date: Wed, 30 May 2012 15:13:03 -0700
Subject: [PATCH] Strip [nil] from parameters hash. Thanks to Ben Murphy for
reporting this!
CVE-2012-2660
Conflicts:
actionpack/lib/action_dispatch/http/request.rb
---
actionpack/lib/action_dispatch/http/request.rb | 22
.../dispatch/request/query_string_parsing_test.rb |7 +-
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/actionpack/lib/action_dispatch/http/request.rb
b/actionpack/lib/action_dispatch/http/request.rb
index 7c8557b..985b730 100644
--- a/actionpack/lib/action_dispatch/http/request.rb
+++ b/actionpack/lib/action_dispatch/http/request.rb
@@ -257,5 +257,27 @@ module ActionDispatch
def local?
LOCALHOST.any? { |local_ip| local_ip === remote_addr && local_ip ===
remote_ip }
end
+
+protected
+
+# Remove nils from the params hash
+def deep_munge(hash)
+ hash.each_value do |v|
+case v
+when Array
+ v.grep(Hash) { |x| deep_munge(x) }
+when Hash
+ deep_munge(v)
+end
+ end
+
+ keys = hash.keys.find_all { |k| hash[k] == [nil] }
+ keys.each { |k| hash[k] = nil }
+ hash
+end
+
+def parse_query(qs)
+ deep_munge(super)
+end
end
end
diff --git a/actionpack/test/dispatch/request/query_string_parsing_test.rb
b/actionpack/test/dispatch/request/query_string_parsing_test.rb
index 071d80c..c7ab700 100644
--- a/actionpack/test/dispatch/request/query_string_parsing_test.rb
+++ b/actionpack/test/dispatch/request/query_string_parsing_test.rb
@@ -81,7 +81,12 @@ class QueryStringParsingTest <
ActionController::IntegrationTest
end
test "query string without equal" do
-assert_parses({ "action" => nil }, "action")
+assert_parses({"action" => nil}, "action")
+assert_parses({"action" => {"foo" => nil}}, "action[foo]")
+assert_parses({"action" => {"foo" => { "bar" => nil }}},
"action[foo][bar]")
+assert_parses({"action" => {"foo"
