Ruby Devs – You’re too trusting. Gems could screw you. » RubySource

rubysource.com

18 points·snikch··3 comments

I take a similar approach. Fork any git-based gems to my account on github, and specify an exact version of each gem I use in my Gemfile, like

gem 'rails', '3.0.7' # for example

And also version the Gemfile.lock file. That way my environment is locked down until I decide to upgrade.

Cool - good to see other people have thought about this aspect too. I guess the pro of locking it down to a version is that you know it's not going to change until you make an active decision to upgrade. The downside being you don't necessarily get any bug fixes or performance increases of minor version updates. Although that's less of an issue if you don't encounter the bugs.

This is exactly what I've been doing since the start of this year - though not for security, but for reliability. I just feel more comfortable knowing that all my developers will be running the exact same specified version of the gems as every body else.

The big downside to this is that by missing out on the small incremental updates, when you do decide to update (or are forced to), then the chances of something breaking are pretty high as you suddenly leap up 27 versions of the gem. (Which of course makes you want to upgrade less often, which just makes the problem worse =)

I really hadn't thought too much about the security implications of the Gems - this is definitely something I'll need to start considering...

Reply on news.ycombinator.com