11–20 of 48 posts
So what was the issue from Rails, specifically?
As a consequence, their search queries were scoped differently than what they had intended. So their choice was roll back the security release, or modify their app to accommodate ActiveRecord's altered behavior.
Heh.
Not worth the heartburn. I've switched to a saner, more tought out framework. Rails is gorgeous, but not safe to use for any serious systems where you're in a small team.
Do you know how many Rails developers I've heard pissing on Flash or Java and its security vulnerabilities? Many - until recently. Now suddeningly these faults are an accepted aspect of Rails development. Really. I guess this more of a rant about how unfairly the Rails community (ie. dhh) has been on others, but now expects critics to look away while it happens in the Rails community on a weekly basis.
Remember - Rails is Omakase - meaning literally 'leave it to someeone else' - food for thought indeed.
Another option is to fork Rails and use the patch files (included with the CVE) that target only the vulnerabilities addressed in the CVE. The problem with upgrading to mitigate security issues is that the Rails team does not release security patches. They bump the minor-minor and do a release. That release almost always includes commits that are unrelated to the security issue. This is especially true when a lot of…
Or don't use Rails.
I've shared my sentiment here before on why I'm not going to use Rails anymore. Imagine having your code working fine, and you update a MINOR version 3.2.x - and your ORM starts returning results that it didn't used to. Heh. Not worth the heartburn. I've switched to a saner, more tought out framework. Rails is gorgeous, but not safe to use for any serious systems where you're in a small team.
I've shared my sentiment here before on why I'm not going to use Rails anymore. Imagine having your code working fine, and you update a MINOR version 3.2.x - and your ORM starts returning results that it didn't used to. Heh. Not worth the heartburn. I've switched to a saner, more tought out framework. Rails is gorgeous, but not safe to use for any serious systems where you're in a small team.
If you're willing to make a slightly different trade-off, just apply the security patches as they come out and don't upgrade minor versions without integration testing.
Do you know how many Rails developers I've heard pissing on Flash or Java and its security vulnerabilities? Many - until recently. Now suddeningly these faults are an accepted aspect of Rails development. Really. I guess this more of a rant about how unfairly the Rails community (ie. dhh) has been on others, but now expects critics to look away while it happens in the Rails community on a weekly basis.
Look, gloating over other people's security issues is shitty behavior, and frankly responsible developers don't do it. Am I calling DHH an irresponsible developer? Yeah. But the Rails core team has thankfully incorporated a number of smart and responsible developers over the past 4 years, and you see a whole lot less shit like that.
Even better, security issues that have languished silently since 2006 are being identified and quickly addressed.
So, no, nobody is asking anybody to look the other way. There are developers who have been in the Ruby and Rails community for a long time, who make no aspirations to being "rockstars" and are out spending their nights and weekends patching rails, and are not slagging other people off for using Java.
Think of them when you feel the inclination to rant.
(also, incidentally, most of the ranting about Flash and Java development have not focused on security issues, they've mainly focused on how awful it is to use those platforms to do development. Which is why things like JRuby are so wonderful. You get to develop in Ruby, and access the JVM's system of libraries.)
Another option is to fork Rails and use the patch files (included with the CVE) that target only the vulnerabilities addressed in the CVE. The problem with upgrading to mitigate security issues is that the Rails team does not release security patches. They bump the minor-minor and do a release. That release almost always includes commits that are unrelated to the security issue. This is especially true when a lot of…
Well - that's enough work to maintain your own app. Maintainging a fork of Rails and drilling through all of the vulnerabilities - that's an extra overhead. It's simpler to regression test your own app, I suppose.
It's easier, from my viewpoint, to stick it out at a release that you know works for you, applying patches from the files contained in the CVEs. There's still a chance that the security patch will cause a regression, but at least you're not pulling in all the interim commits.
Stop today, and help recovering Ruby developers onto a better path!
Give a developer a Ruby-based web framework, and they can run for a day without patching, but give them anything else - even Prolog on Punchcards - and they run for so much longer! Stop today, and help recovering Ruby developers onto a better path!