From: Jeremy Evans <code@...>
Date: 2013-02-18T01:33:51+09:00
Subject: [ruby-core:52390] Re: p385 breaks bakward compatibility

On 02/17 06:23, V?t Ondruch wrote:
> Dne 17.2.2013 1:44, Jeremy Evans napsal(a):
> >>So what worked before update does not work now. This issue was introduced
> >>by rev39101 and there is another similar breakage rev39218 in the queue for
> >>release. Yes, this might be wrong design of Bundler, but considering how
> >>wide is adoption of Bundler, Ruby releases should respect it.
> >I'm the packager of ruby for OpenBSD, and I disagree with this. The
> >included gems that ship with Ruby releases (including patch releases)
> >should have versions that match the versions of the external gems with
> >the same content.
> 
> Actually I agree with you on this. But even more important is to not
> break existing applications. Breaking application will result in
> lost of trust and therefore not updating, keeping security issues
> unfixed.
 
When ruby gems such as rack release new versions with security fixes,
what do you do?  Do you just keep the version the same and apply a
patch, or do you bump the version?

The problem with not updating the version is that you risk hiding
security vulnerabilities.  Let's say you have a project using Bundler
where Gemfile.lock contains a vulnerable gem version.  Trying to
silently fix the vulnerability without changing the version only makes
it more likely that the vulnerable version will stay in Gemfile.lock,
which means that other people using the project (on other operating
systems or non-system ruby installations that don't monkey with the
gem version numbers) will still be using vulnerable code.

IMO, it's better to break the app, alerting the operator to the security
vulnerability in their Gemfile.lock, so they can fix the actual problem.

Bundler's use of Gemfile.lock is similar to statically compiling a C
program, and has the same issues in regards to not automatically picking
up security/bug fixes in libraries.

Jeremy