Fixing Mageia 4 is more important than Mageia 3 as the packages (and a lot of ruby stack) were badly broken in Mageia 3 so no one can be using them.

I starting fixing things for Mageia 3 but that's quite intrusive.

On Mageia 4 rails is usable so it is important to quickly update it there.

Thanks Pascal.  I've punted these issues to Bug 12044 for Mageia 3, so we can use this bug for the Mageia 4 update.

Whiteboard: MGA4TOO, MGA3TOO => MGA4TOO

Updating in Cauldron by Funda.

Version: Cauldron => 4
Whiteboard: MGA4TOO => (none)

According to Fedora, CVE-2014-0080 is in activerecord and CVE-2014-0081 is in actionpack:
https://lists.fedoraproject.org/pipermail/package-announce/2014-March/129715.html
https://lists.fedoraproject.org/pipermail/package-announce/2014-March/129716.html

Summary: ruby-actionpack new security issues CVE-2014-0080, CVE-2014-0081, CVE-2014-0082 => ruby-activerecord and ruby-actionpack new security issues CVE-2014-0080 and CVE-2014-0081

I have updated all packages as they require exact versions but most of them have no other change than the version number.
Installing ruby-rails-4.0.3-1.mga4 ill pull all the others.

Changes:

ruby-activerecord:
 Correctly escape PostgreSQL arrays.
ruby-actionpack:
 Escape format, negative_format and units options of number helpers

No change:

ruby-actionmailer
ruby-activemodel
ruby-activesupport
ruby-rails
ruby-railties

Thanks Pascal!

Advisory:
========================

Updated ruby-activerecord and ruby-actionpack packages fix security
vulnerabilities:

There is a data injection vulnerability in Active Record. Specially crafted
strings can be used to save data in PostgreSQL array columns that may not be
intended (CVE-2014-0080).

There is an XSS vulnerability in the number_to_currency, number_to_percentage
and number_to_human helpers in Ruby on Rails (CVE-2014-0081).

The associated packages have been updated to version 4.0.3 to fix these issues.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0080
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0081
https://lists.fedoraproject.org/pipermail/package-announce/2014-March/129715.html
https://lists.fedoraproject.org/pipermail/package-announce/2014-March/129716.html
http://weblog.rubyonrails.org/2014/2/18/Rails_3_2_17_4_0_3_and_4_1_0_beta2_have_been_released/
========================

Updated packages in core/updates_testing:
========================
ruby-actionmailer-4.0.3-1.mga4
ruby-actionmailer-doc-4.0.3-1.mga4
ruby-actionpack-4.0.3-1.mga4
ruby-actionpack-doc-4.0.3-1.mga4
ruby-activemodel-4.0.3-1.mga4
ruby-activemodel-doc-4.0.3-1.mga4
ruby-activerecord-4.0.3-1.mga4
ruby-activerecord-doc-4.0.3-1.mga4
ruby-activesupport-4.0.3-1.mga4
ruby-activesupport-doc-4.0.3-1.mga4
ruby-rails-4.0.3-1.mga4
ruby-rails-doc-4.0.3-1.mga4
ruby-railties-4.0.3-1.mga4
ruby-railties-doc-4.0.3-1.mga4

from SRPMS:
ruby-actionmailer-4.0.3-1.mga4.src.rpm
ruby-actionpack-4.0.3-1.mga4.src.rpm
ruby-activemodel-4.0.3-1.mga4.src.rpm
ruby-activerecord-4.0.3-1.mga4.src.rpm
ruby-activesupport-4.0.3-1.mga4.src.rpm
ruby-rails-4.0.3-1.mga4.src.rpm
ruby-railties-4.0.3-1.mga4.src.rpm

Assignee: bugsquad => qa-bugs

Any ideas for testing these Pascal please?

That is a good question.  We do have chiliproject, redmine, and mageia-maintainers-database that depend on them, but hopefully there's another way to test rails stuff easily.

I had thought about it but not given any indication as I'm not sure :(

The first one will only impact some usages of PostgreSQL.
The second one will only impact stuff using number_to_currency, number_to_percentage or number_to_human.

I can't think of a way to make sure that nothing broke...

I think testing that the update install cleanly and basic rails usage still works (creating a sample app) is the best we can do.

bug 2638 has some details for testing, mainly the later comments, using chiliproject/redmine seems to test everything necessary and there were at the time some testsuites which ran at build time.

Whiteboard: (none) => has_procedure

Hi all,

running the instructions from the README.urpmi gives me this error in the "rake generate_session_store":

rake aborted!
Bundler couldn't find some gems. Did you run `bundle install`?
/var/www/chiliproject/config/preinitializer.rb:32:in `rescue in <top (required)>'
/var/www/chiliproject/config/preinitializer.rb:27:in `<top (required)>'
/var/www/chiliproject/config/boot.rb:42:in `load'
/var/www/chiliproject/config/boot.rb:42:in `preinitialize'
/var/www/chiliproject/config/boot.rb:24:in `boot!'
/var/www/chiliproject/config/boot.rb:137:in `<top (required)>'
/var/www/chiliproject/Rakefile:4:in `<top (required)>'
(See full trace by running task with --trace)

Regards,

-- Shlomi Fish

CC: (none) => shlomif

(In reply to Shlomi Fish from comment #11)
> Hi all,
> 
> running the instructions from the README.urpmi gives me this error in the
> "rake generate_session_store":
> 
> rake aborted!
> Bundler couldn't find some gems. Did you run `bundle install`?

Then it seems to be missing some dependencies :(

(In reply to Shlomi Fish from comment #11)
> Hi all,
> 
> running the instructions from the README.urpmi gives me this error in the
> "rake generate_session_store":
> 
> rake aborted!
> Bundler couldn't find some gems. Did you run `bundle install`?
> /var/www/chiliproject/config/preinitializer.rb:32:in `rescue in <top
> (required)>'
> /var/www/chiliproject/config/preinitializer.rb:27:in `<top (required)>'
> /var/www/chiliproject/config/boot.rb:42:in `load'
> /var/www/chiliproject/config/boot.rb:42:in `preinitialize'
> /var/www/chiliproject/config/boot.rb:24:in `boot!'
> /var/www/chiliproject/config/boot.rb:137:in `<top (required)>'
> /var/www/chiliproject/Rakefile:4:in `<top (required)>'
> (See full trace by running task with --trace)
> 
> Regards,
> 
> -- Shlomi Fish

OK, for redmine, I was able to get the local webserver (on port localhost:3000) to run using the procedure, and browsed the site. However, I was unable to login ("Sign in") as "admin" with password "admin".

Regards,

-- Shlomi Fish

Pascal what do you make of Shlomi's findings with redmine please, is it likely to be caused by activerecord?

The error is missing the list of missing gems, but I would expect it to be some missing dependencies in the redmine package, unrelated to activerecord.

That was chilliproject, he tried redmine too after that (comment 13) but was unable to log in to it.

Ah yes sorry, shouldn't reply while working :(
I have never used or installed any of them but will have a look tonight.

Tried redmine (without the update):

urpmi redmine
cd /var/www/redmine/
cat >config/database.yml <<EOF
production:
  adapter: sqlite3
  database: db/redmine.sqlite3
EOF
rake generate_secret_token
rake db:migrate RAILS_ENV="production"
ruby script/rails server -e production

And it indeed reject the admin/admin login.

Looking into the db, there is no such account.

on redmine website they list an additional step:

RAILS_ENV=production rake redmine:load_default_data

But it is broken:

Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] en
====================================
Error: Validation failed: Name can't be blank
Default configuration data was not loaded.

It seems it should be created during db:migrate:
db/migrate/001_setup.rb:    user = User.create :login => "admin",

Regarding chiliproject it wants liquid but the dependency is missing in the package.
It also wants acts-as-taggable-on and gravatarify that we don't have in the distribution...

(In reply to Pascal Terjan from comment #19)
> It seems it should be created during db:migrate:
> db/migrate/001_setup.rb:    user = User.create :login => "admin",

Does this indicate a possible issue with activerecord Pascal or an issue with redmine itself, just trying to judge whether it's OK to validate this one.

I am not sure where the problem is, what is sure is that it was already broken before the update and can't be related to it. The update only touches some postgresql code and the problem happens without postgresql being used.

Thanks Pascal, I think we can go with this one then.

Shlomi, would you mind creating new bugs for chilliproject and redmine. Also, which arch did you test with previously? We can add an OK for that one.

Thanks

(In reply to claire robinson from comment #23)
> Thanks Pascal, I think we can go with this one then.
> 
> Shlomi, would you mind creating new bugs for chilliproject and redmine.

OK, I will.

> Also, which arch did you test with previously? We can add an OK for that one.
> 

I think I tested with Mageia 4 x86-64 (which is the first VM I test with).

Regards,

-- Shlomi Fish

Thankyou Shlomi. Pascal we can take your testing into account too if you like, which arch was your testing performed on please?

Whiteboard: has_procedure => has_procedure mga4-64-ok

Mageia 4 x86-64 too

(In reply to Shlomi Fish from comment #24)
> (In reply to claire robinson from comment #23)
> > Thanks Pascal, I think we can go with this one then.
> > 
> > Shlomi, would you mind creating new bugs for chilliproject and redmine.
> 
> OK, I will.

Here:

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

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

Thanks guys, so we still need a test on mga4 32. I'll do that this afternoon if nobody beats me to it.

Tested mga4 32 with redmine as far as http://localhost:3000 and confirmed the login failure.

Whiteboard: has_procedure mga4-64-ok => has_procedure mga4-32-ok mga4-64-ok

Validating. Advisory uploaded.

Could sysadmin please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: has_procedure mga4-32-ok mga4-64-ok => has_procedure advisory mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGASA-2014-0191.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED