Upstream has announced a new version of actionpack, fixing one security issue: http://openwall.com/lists/oss-security/2014/05/06/14 http://weblog.rubyonrails.org/2014/5/6/Rails_3_2_18_4_0_5_and_4_1_1_have_been_released/ The issue is fixed in version 4.0.5, which we should update for Mageia 4. Mageia 3 issues are being tracked in Bug 12044. Reproducible: Steps to Reproduce:
CC: (none) => fundawang, pterjanBlocks: (none) => 12044Whiteboard: (none) => MGA4TOO
Pascal has uploaded ruby-actionpack-4.0.5-1.mga5 for Cauldron.
Version: Cauldron => 4Whiteboard: MGA4TOO => (none)
Debian has issued an advisory for this today (May 16): https://lists.debian.org/debian-security-announce/2014/msg00110.html
URL: (none) => http://lwn.net/Vulnerabilities/599072/
Blocks: (none) => 13659
Pascal has uploaded rails 4.0.7 for Mageia 4, plus the patch in 4.0.8 to fix the regression. I'll post package lists and assign to QA later. Advisory: ======================== Updated ruby-actionpack and ruby-activerecord packages fix security vulnerabilities: Directory traversal vulnerability in actionpack/lib/abstract_controller/base.rb in the implicit-render implementation in Ruby on Rails before 4.0.5, when certain route globbing configurations are enabled, allows remote attackers to read arbitrary files via a crafted request (CVE-2014-0130). PostgreSQL supports a number of unique data types which are not present in other supported databases. A bug in the SQL quoting code in ActiveRecord in Ruby on Rails before 4.0.7 can allow an attacker to inject arbitrary SQL using carefully crafted values (CVE-2014-3483). The associated Ruby on Rails packages have been updated to version 4.0.7, plus the patch from 4.0.8 to fix the regression caused by the CVE-2014-3483 fix. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0130 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3483 http://weblog.rubyonrails.org/2014/5/6/Rails_3_2_18_4_0_5_and_4_1_1_have_been_released/ http://weblog.rubyonrails.org/2014/6/26/Rails-4-1-2-and-4-0-6-has-been-released/ http://weblog.rubyonrails.org/2014/7/2/Rails_3_2_19_4_0_7_and_4_1_3_have_been_released/ http://weblog.rubyonrails.org/2014/7/2/Rails_4_0_8_and_4_1_4_have_been_released/
Pascal uploaded rails (and associated) 4.0.8. Advisory: ======================== Updated ruby-actionpack and ruby-activerecord packages fix security vulnerabilities: Directory traversal vulnerability in actionpack/lib/abstract_controller/base.rb in the implicit-render implementation in Ruby on Rails before 4.0.5, when certain route globbing configurations are enabled, allows remote attackers to read arbitrary files via a crafted request (CVE-2014-0130). PostgreSQL supports a number of unique data types which are not present in other supported databases. A bug in the SQL quoting code in ActiveRecord in Ruby on Rails before 4.0.7 can allow an attacker to inject arbitrary SQL using carefully crafted values (CVE-2014-3483). The associated Ruby on Rails packages have been updated to version 4.0.8, to address these and other issues. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0130 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3483 http://weblog.rubyonrails.org/2014/5/6/Rails_3_2_18_4_0_5_and_4_1_1_have_been_released/ http://weblog.rubyonrails.org/2014/6/26/Rails-4-1-2-and-4-0-6-has-been-released/ http://weblog.rubyonrails.org/2014/7/2/Rails_3_2_19_4_0_7_and_4_1_3_have_been_released/ http://weblog.rubyonrails.org/2014/7/2/Rails_4_0_8_and_4_1_4_have_been_released/ https://bugs.mageia.org/show_bug.cgi?id=13339 https://bugs.mageia.org/show_bug.cgi?id=13659 ======================== Updated packages in core/updates_testing: ======================== ruby-actionmailer-4.0.8-1.mga4 ruby-actionmailer-doc-4.0.8-1.mga4 ruby-actionpack-4.0.8-1.mga4 ruby-actionpack-doc-4.0.8-1.mga4 ruby-activemodel-4.0.8-1.mga4 ruby-activemodel-doc-4.0.8-1.mga4 ruby-activerecord-4.0.8-1.mga4 ruby-activerecord-doc-4.0.8-1.mga4 ruby-activesupport-4.0.8-1.mga4 ruby-activesupport-doc-4.0.8-1.mga4 ruby-rails-4.0.8-1.mga4 ruby-rails-doc-4.0.8-1.mga4 ruby-railties-4.0.8-1.mga4 ruby-railties-doc-4.0.8-1.mga4 from SRPMS: ruby-actionmailer-4.0.8-1.mga4.src.rpm ruby-actionpack-4.0.8-1.mga4.src.rpm ruby-activemodel-4.0.8-1.mga4.src.rpm ruby-activerecord-4.0.8-1.mga4.src.rpm ruby-activesupport-4.0.8-1.mga4.src.rpm ruby-rails-4.0.8-1.mga4.src.rpm ruby-railties-4.0.8-1.mga4.src.rpm
Assignee: bugsquad => qa-bugs
Previously tested with redmine, see comments from here onwards: https://bugs.mageia.org/show_bug.cgi?id=12896#c18
Whiteboard: (none) => has_procedure
(In reply to claire robinson from comment #5) > Previously tested with redmine, see comments from here onwards: > https://bugs.mageia.org/show_bug.cgi?id=12896#c18 I think a specific poc for this bug is not described in the cve. However, your linked test procedure is related to sqlite3 db. Shouldn't this update be tested better with postgresql db, since the update is related to the postgresql support? Furthermore just keep in mind that the described redmine bug seems to be still open (https://bugs.mageia.org/show_bug.cgi?id=13260)
By all means try it with postgresql Marc. There are probably examples on the redmine website how to configure it for that. We're not actually testing redmine, just using it to test these ruby packages. If you know of a better way please go ahead. We've had updates for these packages several times before and redmine is the best method we've got so far.
tested redmin with postgresql (initialized with webmin) and got errors. Installed afterwards redmin with sqlite like in the test Claire had linked in Comment #5 to check. I'm not sure if I get the same errors in both cases, but it seems to be independent of this update. As Claire posted and explained in IRC (and David as well) ruby is unmaintained. So I can really don't tell if this is OK or not :( Tested on MGA4 32bit. It's too late, I'm trying tomorrow again...
CC: (none) => marc.lattemann
Testing mga4 64 with redmine and postgresql9.3 Before: # rake db:migrate RAILS_ENV="production" == Setup: migrating ========================================================== -- create_table("attachments", {:force=>true}) -> 0.0311s -- create_table("auth_sources", {:force=>true}) -> 0.0249s -- create_table("custom_fields", {:force=>true}) -> 0.0233s ...etc == BuildProjectsTree: migrating ============================================== rake aborted! An error has occurred, this and all later migrations canceled: PG::Error: ERROR: column "projects.id" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: ... GROUP BY "lft" HAVING COUNT("lft") > 1 ORDER BY "projects"... ...etc After: # rake db:migrate RAILS_ENV="production" Could not find activesupport-4.0.3 in any of the sources Run `bundle install` to install missing gems. No experience with using rails/rake or ruby come to think of it but unless I'm missing a step after installing the updates this seems like a regression.
I guess something created a Gemfile.lock which fixes the version of dependencies to use so it wants the 4.0.3 :(
Not sure what to do about this one. I've tried redmine, chiliproject and mageia-maintainers-database. Chiliproject appears to be missing requires or perhaps just broken, it also needs altering for apache 2.4 (Order allow,deny etc). Installing it currently kills httpd with a "Syntax error on line 8 of /etc/httpd/conf/sites.d/chiliproject.conf", Options has -Multiviews but no + against the others. Correcting that and following the README.urpmi # rake generate_session_store (in /var/www/chiliproject) rake aborted! Bundler couldn't find some gems. Did you run `bundle install`? ...and a short trace. No go. Redmine is also broken (comment 9) but appears to show a regression (more broken) when these updates are installed. No go. The only other thing which uses ruby-rails is mageia-maintainers-database which seems equally broken. Following the README.urpmi again .. # RAILS_ENV=production rake db:migrate rake aborted! Could not find 'rails' (= 2.3.14) - did find: [rails-4.0.8] ...and a short trace. No go. As everything packaged, which uses rails, seems broken we have no way really to test the updates other than ensuring they install/update cleanly. I know some run self tests during build which is a plus. I don't know the negatives but am aware there are strict version requirements with ruby applications so we risk causing incompatibilities. Pascal/David WDYT ? IMHO these could easily be dropped in mga5.
Whiteboard: has_procedure => has_procedure feedback
(In reply to claire robinson from comment #11) > Pascal/David WDYT ? > > IMHO these could easily be dropped in mga5. I hope your head and the wall will be easily patched, after banging your head against the wall so much here. You've done much more than anyone should be expected to do to try to test this. Thank you and bless you :o) So, IMO, this has been going on for how many years that we haven't been able to get Rails to work properly? I don't mean that as a shot at anyone that's tried packaging it. I know almost nothing about Rails. Apparently it's a house of cards and just too complicated. (I do know that most real-world things that get written in it usually get rewritten in something else once they mature) Anyhow, having it packaged has provided no value for our users, and wasted plenty of valuable Mageia contributor time in trying to get it to work. Yet, we continue to throw more good time after bad in trying to package it, and leave other members of Mageia left to deal with the mess when we have to try to actually support it in a stable release. We can't do it and we've never been able to do it. This goes against the values that Mageia was founded on and makes us look bad. I know sometimes it's hard to let go, but there are many packages that we really should get rid of, and these rank at the top of the list. Maybe we should just say the existing ruby on rails packages in Mageia are unsupported because we can't get them to work, close all of the bugs as WONTFIX, and stop expecting me and the QA team and anyone else who tries to help to keep wasting our time with this. And yes, drop it in Cauldron. I would be interested in hearing Pascal's opinion, and we should raise it on the dev mailing list too, but I don't want to hear any "I think we should keep it (but I don't know how to fix it and I'm sure not going to do it)" arguments. Either we have a viable plan about how we're going to retain these packages going forward, or we drop them.
This also raises something I had already been thinking about lately, and that was before I went back and read some long mageia-dev mailing list threads from 2010 (mostly the mirror layout ones). There was a lot of discussion about what to do about packages that we can't really support. Some wanted a "contrib"-like repository like we had in Mandriva (Fedora is planning to institute something similar). Some wanted to have some external metadata through which we could label packages as supported or unsupported. Some wanted to just drop all unsupportable packages entirely. Maybe now would be a good time to bring back this discussion.
I personally never have used rails, and only fixed the package when it needed to as not many people touch ruby packages... I am not sure if anyone has ever used rails on Mageia, in Mageia 3 it was broken and this was not reported. I'm all for dropping it.
Validating this one. I'll upload the advisory shortly. The packages update cleanly but that is as far as we can test it. It will either be dropped or properly maintained in mga5 depending whether anybody volunteers to adopt it.
Keywords: (none) => validated_updateWhiteboard: has_procedure feedback => has_procedure mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
Advisory uploaded.
CC: (none) => remiWhiteboard: has_procedure mga4-32-ok mga4-64-ok => has_procedure mga4-32-ok mga4-64-ok advisory
Update pushed. http://advisories.mageia.org/MGASA-2014-0303.html
Status: NEW => RESOLVEDCC: (none) => mageiaResolution: (none) => FIXED