Skip to content
Snippets Groups Projects

Update to Rails 4.2.5.2

Merged Paul Mather requested to merge rails_4.2.5.2 into master

Created by: pmather

Update to Rails 4.2.5.2 to address important security advisories: http://weblog.rubyonrails.org/2016/2/29/Rails-4-2-5-2-4-1-14-2-3-2-22-2- have-been-released/

Note: Doing a "bundle update rails" updated rake to 11.x. This causes the current rake tasks to fail due to the lack of a last_comment method, which is deprecated in rake 10.x and removed in rake 11. As a result, we pin rake to a version below 11 for now until the gems we use are all rake 11.x compatible.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Created by: rotated8

    4.2.6 is out now, and looking at the release notes, I think we can move up to that. What do you get installed if you change the Gemfile to gem rails '~> 4.2.5' and run bundle update?

    Which gem is causing us to pin rake? Is it Sufia?

  • Created by: rotated8

    (c.f. 'twiddle-wakka', http://guides.rubygems.org/patterns/#pessimistic-version-constraint)

  • Created by: pmather

    I saw that 4.2.6 was out but also that it is a major upgrade from 4.2.5 (i.e., it is a release rather than just an update). I would rather upgrade to that separately and get this minor update in just to close the security advisories in a timely fashion.

    I'm not confident to specify '~> 4.2' for Rails, especially given this minor update initially broke a major component. Yaay for Rails quality control. :smile:

    I've discovered they've actually since issued a fix for Rake 11.x to deprecate instead of remove the last_comment method. When we do step into the brave waters of 4.2.6, we can remove the current pin for Rake. For now, I'd consider it unnecessary busy work to redo the pull request. Besides, leaving in the pin is a cogent historical reminder of Rails' quality control in action. :smile:

  • Created by: pmather

    Looking at the relevant commit history for Rake (https://github.com/ruby/rake/commits/3948349a82a2522f1d8293093164ef395bee542d/lib/rake/task_manager.rb), the commit on 26th Jan broke things and the commit of 10th Mar fixed it by restoring the method by vocally deprecating it.

  • Created by: rotated8

    Sorry, ~> 4.2.5, not ~> 4.2. Rails (and Rake) follows SemVer, so as long as we don't go to 4.3, we should be ok. These should all be bugfix or security updates.

    Since Rake is fixed now, we should pin it to ~> 11.1.0, or even ~> 11.1. This will keep it for going to 12 and having the same deprecation issue again.

  • Created by: pmather

    I'm leery of using '~> 4.2.5' for Rails because that will install 4.2.6, which, as I said previously, I don't want to do at this time. Some on the Web even suggest using "an exact version in the Gemfile for fragile gems, such as Rails" (https://github.com/thoughtbot/guides/tree/master/best-practices#bundler). Should we?

    Because Rake is fixed now, we may as well just remove the pin to 10.x, like I did for the recent pull request to the ETDplus repository. It just seemed like busy work to redo the pull request to do so, and I'd rather get these security holes patched sooner rather than later...

Please register or sign in to reply
Loading