
Ruby Devs – You’re too trusting. Gems could screw you. » RubySource - snikch
http://rubysource.com/ruby-devs-your-gems-could-screw-you/
======
rawsyntax
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.

~~~
snikch
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.

~~~
davesmylie
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...

