8 ms·
Rails 3.2.12, 3.1.11, and 2.3.17 have been released
- 6thSigma 14y agoAnyone know when 4.0 is coming out?
- knowtheory 14y agoMost of these security vulnerabilities are "stop what you're doing right now and fix this" bugs. Honestly I don't want a Rails 4 until all the rest of this has been shaken free. I'd rather Rails-core and other security minded rubyists keep digging for exploits.
- 6thSigma 14y agoI completely agree. I just heard the release date was imminent back in December. I assume these security bugs are what's postponing it.
- ObnoxiousJul 14y agoThere are so many security issues being unveiled that at this point one might wonder if Rails 4 (and a complete redesign) may not be the way to fix the security issues. Maybe also, if ruby programmers learned to program (instead of doing banana driven lingo development) or committed suicide throwing themselves from a cliff (along with PHP developers) (like lemmings) we could also have a boring yet more secured internet.
- knowtheory 14y agoExcept the internet would still have you to start flamewars about people you didn't like! :P Make no mistake, there are a pile of ruby programmers who do care about security and take this shit seriously. You probably use their code. We're paying for the way that Rails was developed in the days prior to the Rails/Merb merge. There's a reason why the community split in those days. Please don't paint all of us Rubyists with the same brush.
- ObnoxiousJul 14y agoIt is not as if I was not aware that Pypi module distribution (I am a python programmer) is unsecured and that python is lucky enough to have no scrutiny of the community. Discussion on Pypi (catalog-sig) are pretty much advancing in the direction of a kombinat (something to complicated to be even appliable). But I can make sarcasm because nobody will check my claims and will consideer good will and awareness as a good direction. To be honest, the computer industry is like lemmings building a cliff of uselessly complicated stuff from which we will fall. May the computer industry please quietly wait my retirement before crumbling down.
- steveklabnik 14y agoThere is no official date for 4.0. "When it's ready."
- SilasX 14y agoThat's good. The RoR community is very conservative about these things and makes sure to only release after thorough testing.
- steveklabnik 14y agoYour snark isn't very helpful. Every major release goes through a few release candidates. For example, 3.0.0 had 4 beta and 2 RC releases before final. 3.2.0 had two RCs.
- madewulf 14y agoThe release text is not that clear. Is that a new big security issue?
- Xylakant 14y agoThese are new security issues that are mostly related to the latest yaml problems. The issues are explained in detail in the linked CVE. One of the issues affects only rails < 2.3.17, but the second is critical enough to warrant immediate updates unless you're sure you're safe. You should also update your JSON gem.
- breckenedge 14y agoThe CVEs go into more detail. There's a way to circumvent attr_protected.
- viseztrance 14y agoI know we shouldn't rely on security by obscurity but I hope people will stop posting proof of concepts within the first 24 hours of the announcement.
- angersock 14y agoWhat, then we'll have to work for a living? Good thing I hadn't had anything planned this evening. :P
- viseztrance 14y agoI'm not against work. I just realise that my collegue who access to deploy our app is in Japan and won't get up for a few hours. It's just common sense.
- bradleyland 14y agoWhy? The PoC makes it easy to test your apps with tools like Metasploit. The blackhats don't care. They're going to build a sploit anyway, and they're not going to share it so we can use it to test.
- viseztrance 14y agoThere are many smaller targets and this lowers the barrier for script kiddies to an unprecedented level. And it's one thing to detect the exploit and another to actually run it and post it on the web before people have time to patch their installations (talking about hours!).
- bradleyland 14y agoI know this line of reasoning is tempting, but it simply doesn't hold up under scrutiny. Even scriptkiddies know where to get "sploits". The difference is, we won't get those as part of our security tool subscription, so we won't have an easy way to test. There's no hiding when the necessary patches point out exactly where the vulnerability is. Your only choice is to patch immediately. Lamenting the availability of PoC tools for whitehats isn't going to reduce your chances of being hit by a blackhat one iota.
- jasonshen 14y agoNoob question: I just installed the newest version of rails with "gem install rails" but when I run "rails -v" I stil get 3.2.11 How do tell the computer to start using the newest version of Rails?
- josephlord 14y ago'bundle update rails' should do it subject to your Gemfile specifying a particular version.
- jasonshen 14y agoUpdated the Gemfile and ran this command. Worked. Thanks!
- wildster 14y agoChange your Gemfile so it says "gem 'rails', '~> 3.2.12'"
- jasonshen 14y agoAh that's it. I'm going through mhartl's Ruby on Rails Tutorial and he has us specify a Rails version to maintain consistency btw the tutorial and our code. Thanks!
- mhartl 14y agoI use exact gem versions because experience shows that even minor gem updates can break the tutorial. (RSpec is particularly guilty of this.) I generally recommend '~>' for more advanced users, but when getting your bearings I think it's best to use exact versions. That said, I keep the Rails Tutorial and sample application as up-to-date as possible—and in fact both have already been updated with the latest version. :-) http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#sec-install_rails http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#se... $ gem install rails -v 3.2.12 https://github.com/railstutorial/sample_app_2nd_ed/blob/master/Gemfile https://github.com/railstutorial/sample_app_2nd_ed/blob/mast... gem 'rails', '3.2.12'
- travisp 14y agoPlease also note from the blog post that CVE-2013-0269 refers to the "json" gem, which may not get upgraded with the rails gem updates. You may need to add it as a separate dependency to your Gemfile to make sure you are using json version 1.7.7, 1.6.8, or 1.5.5.
- cwzwarich 14y agoShouldn't there be a way for gems maintainers to force/strongly encourage an upgrade when there is a security issue regardless of the transitive nature of the dependency?
- reedlaw 14y agoI just patched a project by updating the Gemfile with the latest Rails version and "bundle update rails" updated the json gem along with it.
- travisp 14y agoI think it depends a lot on your particular configuration, since json is only an indirect dependency in rails (i.e. it's not part of rails's gemspec). It's clear that it won't get updated for everyone, which is why this warning (to make sure json gets updated and possibly add the dependency if needed) has gone out on the rails security mailing list.
- pardner 14y agoThere are two common json gems, one if which is NOT updated when you update rails. json_pure does not seem to be updated to 1.7.7 automatically by 'bundle update rails' so if your Gemfile.lock shows your app uses json_pure (via some other gem's dependency in my case), you also need to run 'bundle update json_pure'
- Harkins 14y agoDoes anyone have a copy of the CVEs that's not on Google Groups? Something in the js or cookie-handling is broken for me and the page includes no text.
- emillon 14y agoHere they are on gmane: [CVE-2013-0276]: http://permalink.gmane.org/gmane.comp.security.oss.general/9350 http://permalink.gmane.org/gmane.comp.security.oss.general/9... [CVE-2013-0277]: http://permalink.gmane.org/gmane.comp.security.oss.general/9351 http://permalink.gmane.org/gmane.comp.security.oss.general/9...
- angersock 14y agoThis is really wonderful work, both from the investigators who've documented and described the vulnerabilities and the Rails folks for being quick to fix them. My co-founder and I had talked about YAMLgate when it had happened--our conclusion was that Rails is going to be under very close scrutiny for a while, and that there will be a lot of these things found, but that the framework will be all the stronger for it. Always bear in mind this: even if it means more work for admins and devs, this promptness of response and willingness to admit failings is a sign of a healthy ecosystem.
- polemic 14y agoCan anyone explain why boosterism gets upvoted so much on these RoR vuln posts? RoR maintainers should be commended for their ongoing prompt responses to defects, but the likelihood ...that there will be a lot of these things [still to be] found... is not something to celebrate. Every project has bugs, every framework has it's security problems, but the severity and frequency of the issues is such that many will conclude that RoR is not mature, stable or safe enough for production use. I can only conclude that a large proportion of HN readers have most of their eggs in the RoR basket, so spinning this into a positive is the best way to convince themselves that "..more work for admins and devs.." is a GOOD thing.
- angersock 14y agoI'd be doing the same thing if there was an announcement about Khronos fixing the perennial retardation of the OpenGL API, or of a new batch of bugfixes for some of the Java stuff I used to use, or whatever else--I'd support them all the same. Anything that helps encourage people to be open about their work and honest in their failings in our industry is, in my book anyways, a Good Thing. Don't be hating on Ruby folks for trying to encourage good development practices.
- polemic 14y agoFrom a triage point of view, Ruby/RoR is excellent. I'm not trying to hate on Ruby people - the community is amazing and the inherent openness and transparency is to be lauded. That's not my issue though. The project's reputation is fiercely protected by it's community - and I wonder at what point this could be damaging. To borrow some terminology, they're not `user-space` bugs like the majority of PHP security flaws (for example). They're bugs in the firmament. Talking to penetration testers, you often hear this story: if it's .NET, you're going to have a hard time; If it's PHP, you can count on the developer leaving an injection flaw of varying exploitability; If it's RoR, you can count on an out of date package with a critical flaw that bypasses the app entirely. (btw: I'm primarily a python/django person - I won't comment on that!).
- bratsche 14y agoThere have been other commits that made it into the 3-2-stable branch, and I would have expected that those fixes would have made it into the next 3.2.x release, but that's not the case. Is that normal for Rails updates? For example, https://github.com/rails/rails/pull/8718 https://github.com/rails/rails/pull/8718 is a PR that was merged into 3-2-stable to deal with a regression in 3.2.8.
- steveklabnik 14y agoIt is my understanding that security updates are generally made by taking the last released version, applying the security patches, releasing, and then applying the patches to the end of 3-2-stable. This makes it incredibly easy for people to upgrade, and minimizes chances of regressions. The next non-security release of 3.2.x should include that change.
- bratsche 14y agoCool, thanks for the clarification Steve.
- DanielKehoe 14y agoUpdating Rails (an article with details and advice): http://railsapps.github.com/updating-rails.html http://railsapps.github.com/updating-rails.html Let me know if I got anything wrong. It's for anyone who is not sure how to upgrade to a new Rails version.
- foobar2k 14y agoIt is also important to note that at least the 3.2.12 release forces you to upgrade rack too. This is due to seperate vulnerabilities reported in rack recently (see http://rack.github.com/ http://rack.github.com/).
- timr 14y agoSo, why did the Rails maintainers arbitrarily decide to stop supporting 3.0.x versions, while still supporting 2.3.x versions?
- jbverschoor 14y agobecause it's easy to upgrade to 3.2
- deleted 14y ago[deleted]
- steveklabnik 14y agoMany people get stuck at the (X-1).Y release of x.y.z versions. This is because upgrading x-1 to x can be difficult and costly. So there's a good reason to support both x and x-1, but less of a good case to support y, y-1, AND y-2: those people can more easily upgrade to y-1. So, as you can see, it's not arbitrary: x and x-1 are supported, y and y-1 are supported. Just no series as of two revisions ago.
- timr 14y agoIt's fairly arbitrary. There were changes between Rails 3.0.x and 3.1.x that broke many popular gems (e.g. Devise). A lot of people get stuck at that transition, because it's difficult and costly. This just seems like laziness. At the very least, you don't just suddenly choose to end-of-life a version of software that's still in wide distribution. Give people a bit of notice!
- steveklabnik 14y agoYou can call any decision 'arbitrary,' I guess. I mean it has internal logic. Notice was given, in the post spelling out which versions are still supported a few weeks ago.
- timr 14y ago
- venus 14y agoMeh. I don't use attr_protected anyway, and neither should anyone else. Security 101 - whitelist, don't blacklist. That said the JSON issue looks worrying, so an update and redeploy is necessary.
- lucisferre 14y agoI've already switched to using the strong_parameters gem. I'd recommend it to anyone else starting a new rails 3 project.
- venus 14y ago+1 to this. For new projects I'd probably just go with 4.0 beta though, it's almost ready...
- lucisferre 14y agoI can't completely agree with that. I spent some time with 4.0 with the intention of building on it but found too many broken Gems to be productive with it. If you don't intend to use many (or any) third-party Gems it's less of a problem.