[ruby-core:52399] Re: p385 breaks bakward compatibility

Dne 17.2.2013 17:33, Jeremy Evans napsal(a):
> 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?

This is not so simple question as it looks.

First take a look on situation prior Bundler was invented. At that days, 
it was typically not an issue to bump version. However, there were 
notable exceptions, such as Ruby on Rails, which:
1) always hardcoded their version into newly generated application.
2) hardcode version dependencies of it 8 core components. That means 
fixing one security bug in one component would mean update all 8 
components. That is not right.

Later, when Bundler came on the scene and started to lock version into 
Gemfile.lock, there is *no way* how to bump gem version in system 
without breaking application.

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

Take it opposite way, you are maintaining Ruby and you are responsible, 
that after update of Ruby, every system no matter what, continues to 
work. You have no clue what software is running on that computers nor if 
it is using Bundler or something different. So what would you do?

Actually the security vulnerability should be covered by your regression 
tests and QA. Blindly trust to versions is useless, since security 
vulnerabilities might be reintroduced from time to time. Also what 
Brakeman [1] does is not the right approach. Instead of testing if the 
application is vulnerable or not, it tests version numbers [2]. Sorry to 
say that, but that proves nothing.

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

I have different example for you. The shared libraries can be exchanged 
as long as their ABI is compatible. Since update to RDoc did not changed 
the ABI, the application should continue to work. But due to design flaw 
of Bundler, it will not continue to work.

The only question is if it is worth of redesign Bundler or if Ruby 
should accept existence of its design.

V咜



[1] http://brakemanscanner.org/
[2] 
https://github.com/presidentbeef/brakeman/blob/master/lib/brakeman/checks/check_yaml_parsing.rb