As Rèmy didn't respond in time, i'll assign this to me, as i've already committed the fixes for this.

Status: NEW => ASSIGNED
CC: (none) => doktor5000
Assignee: shikamaru => doktor5000

Updates for ruby-actionpack and ruby-activerecord have been submitted to updates_testing, that should fix the security issues. Please test them.
They are ruby-activerecord-2.3.11-1.1mga1 and ruby-actionpack-2.3.11-1.1mga1.


Advisory for ruby-actionpack

This security update fixes the following issues:
CVE-2011-2931
"A cross-site scripting (XSS) vulnerability had been found in the strip_tags helper. An parsing error can be exploited by an attacker, who can confuse the parser and may inject HTML tags into the output document."

CVE-2011-3186
"A newline (CRLF) injection vulnerability had been found in response.rb. This vulnerability allows an attacker to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via the Content-Type header."



Advisory for ruby-activerecord
This security update fixes the following issues:

CVE-2011-2930
"An SQL injection vulnerability had been found in the quote_table_name method that could allow malicious users to inject arbitrary SQL into a query."

There are no POCs for these CVEs, only "An attacker can use a browser to exploit these issues."

We will be limited to testing ruby-actionpack and ruby-activerecord for functionality but no ideas yet how to do that :\

Do we have an ruby on rails devs to give guidance?

CC: (none) => eeeemail

Adding shikamaru to CC in case he can offer assistance.

CC: (none) => shikamaru

Created attachment 800 [details]
Output of rake --trace test_all

I'm probably doing something wrong, but from http://ap.rubyonrails.org/
under run unit tests (in the Files section), I get the impression
rake can be used to run the tests.

Not working here.

Well, at least for ruby-activerecord, there is a whole %check section which is run during build, see the SPEC: http://svnweb.mageia.org/packages/updates/1/ruby-activerecord/current/SPECS/ruby-activerecord.spec?revision=142685&view=markup
So there is already some minimal testing.

Ping?

The activerecord testing looks quite complete with its own tests during the build, it creates databases and tests them on mysql and postgresql.

If we accept that as tested we still need testing of actionpack somehow.

Looking into this more, I decided that for testing, I'd run a program that
requires ruby-actionpack and ruby-activerecord.

Looking at the whatrequires-recursive for both, I chose chiliproject.

[root@hodgins ~]# urpmi chiliproject
The following package cannot be installed because it depends on packages
that are older than the installed ones:
chiliproject-1.2.0-1.mga1
Continue installation anyway? (Y/n) n
[root@hodgins ~]# urpmq --requires chiliproject
--requires behaviour changed, use --requires-recursive to get the old behaviour
webserver
rubygem(rails)[== 2.3.11]
rubygem(rack)[== 1.1.0]

Looks like this update cannot be installed, until all packages that require
specific versions of the ruby packages are updated too.

How common is it for version specific requires to be used for ruby packages?

CC: (none) => davidwhodgins

Dave, the update doesn't change any version numbers, so that can't be the cause of the issue you are having. Can you provide the output of "urpmi --debug chiliproject"?

CC: (none) => anssi.hannula

Created attachment 818 [details]
debug output of urpmi

chiliproject currently strictly requires rubygem(rack) = 1.1.0 which is the cause of the problem. And normally such really strict requires are there for a reason.

Mageia 1 has ruby-rack 1.1.0, from where is the 1.1.2 coming from?

teambox appears to use both ruby-actionpack and ruby-activerecord too so if that works well then I guess we can say these two must be Ok.


Well done Dave, thats a useful command!

No luck getting teambox to install properly so far.

It installs with teambox-httpd to /var/www/teambox

Configured teambox.yml and then installed teambox-mysql and configured databse.yml

It keeps saying file not found mysql and to gem install mysql. Doing so brings up a huge list of options. A bit of googling I found it needs 

gem install mysql -- --with-mysql-config=/usr/bin/mysql_config

which brings up different errors. After all that it still says it cant find mysql. I've tried with sqlite3 too with no success. This is becoming a marathon!


There are some instructions here which might help if you can get past this bit:-

https://github.com/teambox/teambox/wiki/installing-locally

(In reply to comment #13)
> Mageia 1 has ruby-rack 1.1.0, from where is the 1.1.2 coming from?

http://mageia.c3sl.ufpr.br/distrib/1/i586/media/core/backports_testing/ruby-rack-1.1.2-1.mga1.noarch.rpm

The file's date is June 22nd.  When this package is validated, should we
request deletion of the packages ruby-rack and ruby-rack-doc from
Core Backports Testing?

I've disabled core backports testing, and reinstalled ruby-rack.

I've now installed chiliproject and teambox.  I'll test them out now.

Trying to get chiliproject running, following the instructions at
https://www.chiliproject.org/projects/chiliproject/wiki/Installation

The step "bundle exec rake generate_session_store" fails with unable
to fine Gemfile.  I found one for teambox, so tried copying that
one to /var/www/chiliproject.  The generate session store then seems
to work.

The next step "RAILS_ENV=production bundle exec rake db:migrate",
fails with ...
Missing these required gems:
  rubytree  
  coderay  ~> 0.9.7
You're running:
  ruby 1.8.7.334 at /usr/bin/ruby
  rubygems 1.5.2 at /root/.gem/ruby/1.8, /usr/lib/ruby/gems/1.8
Run `rake gems:install` to install the missing gems.

Stuck at this point.

I think we are going to have to admit defeat with this one. There was no response for requests for help.

Seeing as ruby-activerecord contains quite good testing as part of the build I suggest we validate at least that one and perhaps trust that Florian has good magic for the other. This will be sat here for ever otherwise.

What do we think?

In sent a message directly to shikamaru in case he is reachable (I see him tweet from time to time, so he's alive :)) and would find a few minutes to test it or tell us how to test.

(In reply to comment #19)
> In sent a message directly to shikamaru in case he is reachable (I see him
> tweet from time to time, so he's alive :)) and would find a few minutes to test
> it or tell us how to test.

Read "I", not "In"

CC: (none) => stormi

Stormi: Check #c1 and #c4 i've already tried to reach him via mail before i commited the fixes, and tried to reach him on IRC, where he didn't answer to me even when he was available. Rather sad.

Maybe pterjan knows something about this, as he is ruby maintainer?

FWIW, just seen that now, seems shikamaru is excluded for comments on this bug. Somebody said he had some problems with this mailserver some time ago.

(In reply to comment #18)
> I think we are going to have to admit defeat with this one. There was no
> response for requests for help.
> 
> Seeing as ruby-activerecord contains quite good testing as part of the build I
> suggest we validate at least that one and perhaps trust that Florian has good
> magic for the other. This will be sat here for ever otherwise.
> 
> What do we think?

I would really prefer it, if someone could confirm comment 17 was caused
by problems in the chiliproject package, or my configuration of it, but
as this is a security update, I think we'll have to go ahead and validate it,
and sort out any problems with it later.  Agreed?

Hi, Iâve looked at the history of this bug, hereâs some guidance. Iâm sorry for not being able to help you a lot on this, Iâm very busy at the moment, I hope Iâll be able to be more available starting from January.

So, first thing about how rails was packaged. You have noticed that activerecordâs got a very complete test suite. The thing is that activating unit tests for the other gems would bring in circular dependencies, as packages require each other, not really an option, it would be a PITA to perform an upgrade after that, since they all have strict version dependencies on each other.

As for Chiliproject, but thatâs also true for nearly all rails apps: they are tied to a particular version of rails, so any rails upgrade needs to be well tested on these apps, and either patch the file where this version is set or upgrade this software if it is needed.

In the case of Chiliproject, such an upgrade exists, 2.0.0 uses rails 2.3.12. The problem is that this is a new major version, and among other things it integrates bundler which might break a lot of things, especially in terms of packaging. So, not my preferred option in this case.

If you go for the patch, the file where it is set is config/environment.rb and there is already a patch for it, see http://svnweb.mageia.org/packages/cauldron/chiliproject/current/SOURCES/chiliproject-1.1.0-fix-rails-version.patch?revision=61385&view=markup

As for the strict require on rack in #12, it was added because rack is also available on version 1.2.0 and later, which is not compatible, I wanted to be sure it did not get broken and unnoticed if someone accidentally upgraded rack to this version or a later one.

In reply to #5: tests fail because none of the test suite is included in the package. Granted, if we do not execute the test suite at build time, we should at least make a -devel subpackage to include them and allow you to execute the testsuite. The reason behind this is to leave the package at a reasonable size.

In reply to #15: you do not need to do that and you are not encouraged to do so. The mysql gem has some .so files, meaning you need every -devel package for the gem to install properly, you should use the ruby-mysql package which contains this gem. Besides, chiliproject -mysql subpackage should already pull ruby-mysql so you shouldnât have to install it manually.

In reply to #17: yes it is wrong, these instructions are for a later version of chiliproject, which integrates bundler tightly. Take a look at the README.urpmi thatâs included in the package, it contains correct instructions to get chiliproject working under mageia.

Now, to the point: the way we can test if ruby-actionpack is ok is the following:
- make a -devel package that contains the missing directories and files for the testsuite (I guess, test/ and Rakefile)
- install both ruby-rails and ruby-actionpack-devel and run the test suite within its directory

Sorry for the inconvenience, I tried to generalize tests as much as possible during build time, but I should have added the test suites in -devel subpackages where it would not be possible and/or cause too much maintainance headaches.
Sorry for not being able to give much time to it either :/

> In reply to #17: yes it is wrong, these instructions are for a later version of
> chiliproject, which integrates bundler tightly. Take a look at the README.urpmi
> thatâs included in the package, it contains correct instructions to get
> chiliproject working under mageia.

There's a few minor problems with the README.urpmi.

It omits the need to "cd /var/www/chiliproject" before running the commands.
The loading of default data fails.

I've figured out that redmine has been properly setup. first. I've created
the redmine mysql user and database, pretty much by following the instructions
for the chiliproject, since it doesn't have a readme.urpmi

I have the redmine test server working, but trying to access the regular
server with http://127.0.0.1//redmine fails with ...
Routing Error
No route matches "/redmine" with {:method=>:get}

From what I could find with google, I've added ...
tail -n 1 /var/www/redmine/config/environments/production.rb
config.action_controller.relative_url_root = '/var/www/'

but I'm still getting the routing error for both redmine and chiliproject,
so I'm stuck again.

No sooner do I save that comment, and I realize I should be able to
access the chiliproject using the test server in /var/www/chiliproject.

ruby script/server -e production
then allows me to connect to 127.0.0.1:3000, where I've been able
to login to admin, password admin, change the password, etc.

I've created a project, added a user, signed on as that user,
added some issues, etc.

Everything seems to be working ok.  Is there anything specific I should
test to ensure ruby-actionpack and ruby-activerecord have been used?

well, the moment you ran db:migrate you already used activerecord since it provides an abstraction to databases, so you already populated the database with test data. Since the test suite is run at buildtime, and since the patch added a test for the quote_table_name method, I guess itâs fine since the package would have failed to build otherwise.

ActionPack, among other things provides helpers for url rewriting, so as soon as you created a test project and accessed to it you already used it. But to specifically test the CVE you would have to try to access a project that does not exist and include some special characters in the URI and see if they get sanitized (like CR-LF in one of the URI component). For the second link, a test has been added in the test suite to check if the text was correctly sanitized, so I guess you would have to run the test suite.

To me the update looks ok, though.

Is there much difference between the i586 and x86-64 version?

Anyone object to validating this update then?

none, actually, since they are noarch

Ok.  Validating the update.

Can someone from the sysadmin team push the srpm packages
ruby-activerecord-2.3.11-1.1.mga1.src.rpm
ruby-actionpack-2.3.11-1.1.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory:
This security update fixes the following issues:
CVE-2011-2931
"A cross-site scripting (XSS) vulnerability had been found in the strip_tags
helper. An parsing error can be exploited by an attacker, who can confuse the
parser and may inject HTML tags into the output document."

CVE-2011-3186
"A newline (CRLF) injection vulnerability had been found in response.rb. This
vulnerability allows an attacker to inject arbitrary HTTP headers and conduct
HTTP response splitting attacks via the Content-Type header."

CVE-2011-2930
"An SQL injection vulnerability had been found in the quote_table_name method
that could allow malicious users to inject arbitrary SQL into a query."

https://bugs.mageia.org/show_bug.cgi?id=2638

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

update pushed.

Status: ASSIGNED => RESOLVED
CC: (none) => dmorganec
Resolution: (none) => FIXED