p385 breaks bakward compatibility

[Vít Ondruch]

Hi,

Could you please avoid bumping versions of bundled gems when fixing security issues? The version bump breaks the promise of point release to do not break anything and update safely.

Consider following simple case:

$ ruby -v
ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-linux]

$ rdoc --version
rdoc 3.9.4

$ cat Gemfile
gem 'rdoc'

$ cat testrdoc.rb
require 'rdoc/rdoc'

options = RDoc::Options.new
options.parse ARGV

rdoc = RDoc::RDoc.new
rdoc.document options

$ bundle install
Using rdoc (3.9.4)
Using bundler (1.1.4)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

$ bundle exec ruby testrdoc.rb -- testrdoc.rb
Parsing sources...
100% [ 1/ 1]  testrdoc.rb                                                      

Generating Darkfish format into /tmp/test374/doc...

Files:      1

Classes:    0 (0 undocumented)
Modules:    0 (0 undocumented)
Constants:  0 (0 undocumented)
Attributes: 0 (0 undocumented)
Methods:    0 (0 undocumented)

Total:      0 (0 undocumented)
  0.00% documented

Elapsed: 0.0s

$ bundle exec ruby testrdoc.rb -- testrdoc.rb
Could not find rdoc-3.9.4 in any of the sources
Run `bundle install` to install missing gems.

$ sudo yum update 'ruby*' # Or just install somehow new point release of Ruby

$ ruby -v
ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-linux]

$ rdoc --version
rdoc 3.9.5

$ bundle exec ruby testrdoc.rb -- testrdoc.rb
Could not find rdoc-3.9.4 in any of the sources
Run `bundle install` to install missing gems.

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.

Please note that I added also bundler ML in copy, may be somebody of Bundler guys will reconsider their design.

Thank you

Vít

[Luis Lavena]

On Thu, Feb 14, 2013 at 6:06 AM, Vít Ondruch <v.on...@gmail.com> wrote:
> Hi,
>
> Could you please avoid bumping versions of bundled gems when fixing security
> issues? The version bump breaks the promise of point release to do not break
> anything and update safely.
>

The bump is due RDoc be actually 3.9.5, as it was released to rubygems.org:

http://rubygems.org/gems/rdoc/versions/3.9.5

If no bump was produced, how you will differentiate between broken
3.9.4 and patched 3.9.4?

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[Alex Chaffee]

1. Your Gemfile doesn't specify any sources. If it did, Bundler could find whatever version of rdoc it needs.  Read http://gembundler.com/man/gemfile.5.html 

2. Your Gemfile.lock file is probably locking to a version of rdoc that doesn't exist in your new installation of Ruby. Do "bundle update" to reset your Gemfile.lock. 

3. Updating Ruby is not guaranteed to copy over old gems into your new installation. RVM can be told to do this but it appears that yum does not. 

4. My version of Bundler warns me when my Gemfile has no sources when I do "bundle install". Since you never ran "bundle install" (despite it clearly telling you to) I have no idea if you're using the latest version. Do "gem update bundler" to install the latest. 

5. Dot releases are not guaranteed not to break anything. Read semver.org for one (popular, but not mandatory) interpretation of what release numbers should promise. 

6. Gems are kind of complicated, but once you understand the basics, they're pretty easy to use. I see no bug here, just you misunderstanding the tools. 

7. You do realize what version numbers are for, right? Version numbers identify versions. If the code changes, even to fix a bug, it's not the same code, which means it's a different version. So it needs a new version number. 

- A

--
You received this message because you are subscribed to the Google Groups "ruby-bundler" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-bundler...@googlegroups.com.
To post to this group, send email to ruby-b...@googlegroups.com.
Visit this group at http://groups.google.com/group/ruby-bundler?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[v.on...@gmail.com]

Dne pátek, 15. února 2013 12:20:18 UTC+1 Alex Chaffee napsal(a):

1. Your Gemfile doesn't specify any sources. If it did, Bundler could find whatever version of rdoc it needs.  Read http://gembundler.com/man/gemfile.5.html 

Not sure what is the relevance here
 

2. Your Gemfile.lock file is probably locking to a version of rdoc that doesn't exist in your new installation of Ruby. Do "bundle update" to reset your Gemfile.lock. 

Clearly not, because I update Ruby in the meantime, therefor RDoc 3.9.4 were replaced by RDoc 3.9.5, that is the point. I don't want to run bundle update. Note that I am speaking as of packager of Ruby on Fedora. There is no way for me to know where are you application installed and how to call "bundle update" on them.
 

3. Updating Ruby is not guaranteed to copy over old gems into your new installation. RVM can be told to do this but it appears that yum does not. 

This is irrelevant. RDoc is bundled in Ruby and I worked with plain Ruby installation.

4. My version of Bundler warns me when my Gemfile has no sources when I do "bundle install". Since you never ran "bundle install" (despite it clearly telling you to) I have no idea if you're using the latest version. Do "gem update bundler" to install the latest. 

5. Dot releases are not guaranteed not to break anything. Read semver.org for one (popular, but not mandatory) interpretation of what release numbers should promise. 

Yes, semver guarantees that, but bundler does not reflect that, since the versions are locked. I have to do something more, such as "bundle update" to actually update my application
 

6. Gems are kind of complicated, but once you understand the basics, they're pretty easy to use. I see no bug here, just you misunderstanding the tools. 

I know what gems are ... but you live just in gems world. I live in the world where gems are repackaged and somebody relies that nothing breaks due to update and I don't have to run some additional commands due to update.
 

7. You do realize what version numbers are for, right? Version numbers identify versions. If the code changes, even to fix a bug, it's not the same code, which means it's a different version. So it needs a new version number. 

Yes, I do realize. And therefore Bundler should respect ~> dependency and automatically pickup newer version, not just rely on Gemfile.lock.


Vít 

[Vít Ondruch]

Dne 17.2.2013 1:44, Jeremy Evans napsal(a):

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

> Ruby releases should not violate common sense just to work around
> design flaws in ruby libraries, no matter how popular those libraries
> are.

I agree even with this, that is why I am adding Bundler ML on CC. As a
interim solution, until Bundler gets fixed, I hope that #7869 will get
accepted.

V�t

[André Arko]

On Feb 17, 2013, at 1:23 AM, Vít Ondruch <v.on...@gmail.com> wrote:

Ruby releases should not violate common sense just to work around
design flaws in ruby libraries, no matter how popular those libraries
are.

I agree even with this, that is why I am adding Bundler ML on CC. As a interim solution, until Bundler gets fixed, I hope that #7869 will get accepted.

Bundler was created specifically so that this WOULD happen. I realize that the situation is unpleasant for your particular use-case, but Bundler is never going to compromise its core design principles in order to make the case you are describing work. Sorry. :(

That said, the issue you are describing should _never_ be a problem in real life. Any time you update your ruby version, you absolutely need to run `bundle install` again, to make sure that any compiled gems are compiled correctly for the new ruby version that you have just installed. If you run `bundle install` during your reproduction case, the problem goes away completely:

$ ruby -v

ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-darwin12.2.1]

$ cat Gemfile

source 'http://rubygems.org'

gem 'rdoc'

$ bundle exec rdoc --version

rdoc 3.9.4

# update ruby versions

$ ruby -v

ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-darwin12.2.1]

$ bundle install

ERROR: Gem bundler is not installed, run `gem install bundler` first.

$ gem install bundler

Fetching: bundler-1.2.4.gem (100%)

Successfully installed bundler-1.2.4

1 gem installed

$ bundle install

Fetching gem metadata from http://rubygems.org/.........

Installing rdoc (3.9.4)

Using bundler (1.2.4)

Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

$ bundle exec rdoc --version

rdoc 3.9.4

[Vít Ondruch]

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�t



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

[v.on...@gmail.com]

Dne neděle, 17. února 2013 20:39:50 UTC+1 Andre Arko napsal(a):

First and foremost, it is not exactly my problem. I am fighting here for every Fedora, RHEL and CentOS user in the world and possibly also other Linux distributions. This issues makes impossible to use Ruby packaged in system! I am not speaking about some poor souls who tries to use gems distributed with the system and even collaborate with users of other platforms.

Bundler does this collaboration very hard and especially Gemfile.lock makes it almost impossible. The original idea of storing Gemfile.lock in you SCM works just in case you will neglect system packages and you work only with RubyGems itself. Of course RubyGems fails as soon as you try to install some database binding or XML parser, so neither usage of RubyGems is win.

Could you please reconsider your statement. Thank you.

Vít

[André Arko]

On Feb 17, 2013, at 12:25 PM, v.on...@gmail.com wrote:

First and foremost, it is not exactly my problem. I am fighting here for every Fedora, RHEL and CentOS user in the world and possibly also other Linux distributions. This issues makes impossible to use Ruby packaged in system! I am not speaking about some poor souls who tries to use gems distributed with the system and even collaborate with users of other platforms.

Using Ruby packaged in the system is great! It just means that you cannot also be a Bundler user. That is okay — Bundler's goals are directly contradictory with the goals of packaging Ruby into the system.

Bundler is not for managing the dependencies of libraries. It is for managing the dependencies of applications. If an application has its dependencies provided by system packages, Bundler is not needed. In a Rails application, for example, OS packagers should delete at least the Gemfile.lock and possibly also the Gemfile to ensure that the application will use the gems provided by system packages instead of looking for the gems that were locked by the developers of the application. That of course means the application may not work, but that's already an issue when using OS packages.

Bundler does this collaboration very hard and especially Gemfile.lock makes it almost impossible. The original idea of storing Gemfile.lock in you SCM works just in case you will neglect system packages and you work only with RubyGems itself. Of course RubyGems fails as soon as you try to install some database binding or XML parser, so neither usage of RubyGems is win.

If you need to use only gems that are provided by operating system packages, then `bundle install` will not help you, and you should delete the Gemfile.lock.

Could you please reconsider your statement. Thank you.

Bundler exists specifically to guarantee that the exact same code the developer ran is the code you are now running. It is not a design flaw that Bundler loudly refuses to allow different gem versions, it is the entire design. Since you don't want that, you should not use Bundler. I hope that helps.