Forum: Ruby-core p385 breaks bakward compatibility

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


Vt

On Thu, Feb 14, 2013 at 6:06 AM, Vt Ondruch <v.ondruch@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?

Dne 15.2.2013 2:49, Luis Lavena napsal(a):

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

On 02/14 06:06, V?t Ondruch wrote:
>
> options.parse ARGV
> $ bundle exec ruby testrdoc.rb -- testrdoc.rb
> Constants:  0 (0 undocumented)
> Run `bundle install` to install missing gems.
> $ 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.

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.

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

Jeremy

Dne 17.2.2013 1:44, Jeremy Evans napsal(a):
>> ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-linux]
>> options = RDoc::Options.new
>>
>> Modules:    0 (0 undocumented)
>> Could not find rdoc-3.9.4 in any of the sources
>>
> 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

Patch releases are considered as a normal teeny release.
(Ruby's versioning policy is different from normal one because of
historical reasons)

Therefore it is natural that bundled libraries may change its teeny
versions.


2013/2/17 Vt Ondruch <v.ondruch@gmail.com>

On 02/17 06:23, V?t Ondruch wrote:
> 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

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

Dne neděle, 17. února 2013 20:39:50 UTC+1 Andre Arko napsal(a):
> interim solution, until Bundler gets fixed, I hope that #7869 will get
> run `bundle install` again, to make sure that any compiled gems are
>
>
> bundled gem is installed.
>
> $ bundle exec rdoc --version
> rdoc 3.9.4
>
>
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