Issue #5481 has been updated by akihikodaki (Akihiko Odaki).


Hi, I have some feedback implying a possibility of unexpected dependency on features packaged in Ruby installation when their gem versions are intended to be used.

I use Bundler v1.13.7 provided by CentOS SCL. The version always uses `openssl` packaged in Ruby installation even if there is a bundled one.
That is caused by an dependency of Bundler on `openssl`. The dependency is *implicitly* made by `securerandom`. It is not documented in `openssl` documentation, and the documentation `securerandom` just says it may use `openssl` as random generator.

Though the dependency is removed by https://github.com/bundler/bundler/commit/6167ec85e9ef4e9146fad305864b8359d4a9b021, the commit message describes the change as performance improvement, showing the developers were not aware of the dependency on `openssl` and it was locked-in. I searched Bundler's issue tracker for related issues but had no luck.

This case reveals a fact that features packaged in Ruby installation can unexpectedly be used, and users may not be aware of that.
It is problematic especially for such a security-related one. The issue points out security fixes as motivation, but it is hardly *secure* when it can be implicitly disabled.

Here I suggest two possible solutions for the problem:
* Document dependencies of standard libraries on gemified features
* Let RubyGems and Bundler warn if a gemified feature is already loaded

The later solution should actually be done in RubyGems and Bundler, but I decided to share it in this issue since it is the only reason such a warning should be implemented. I have not posted the feedback on the issue tracker of RubyGems nor one of Bundler, so they should be notified later if you think the problem should be handled by them.

----------------------------------------
Feature #5481: Gemifying Ruby standard library
https://bugs.ruby-lang.org/issues/5481#change-66850

* Author: nahi (Hiroshi Nakamura)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* Target version: next minor
----------------------------------------
=begin

Up-to-date summary of this proposal is at ((<URL:https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem>))

== Motivation

 * ruby's release cycle is slow for some standard libraries;
   * ex. security fix for WEBrick, xmlrpc and Zlib.
   * ex. API iteration for net/http, OpenSSL, json, psych, RDoc, minitest and rake.
 * There's already the feature called 'default gems' in ruby and some stdlibs are already using it:
   * rake, rdoc, minitest, json, io-console, bigdecimal
   * And some gems are already doing out-of-band releases.
 * When releasing we should give independence equally to all stdlibs, but in a consistent and controllable way.

== Proposal

 * Allow out-of-band stdlib releases.
   * We are not proposing changes to ruby's release management, the release manager would decide when they release ruby and stdlib.
 * Allow more stdlibs to be installed as a 'default gem'
 * Register these gems on RubyGems.org
   * Introduce a new mechanism: controlling supported ruby version so that we can avoid installing unexpected version of stdlib gems.
     For example, a WEBrick gem for ruby 2.0.1 (released from ruby_2_0_1 branch) should not be installed for ruby 2.0.0 (released from ruby_2_0_0 branch) unless we know it works for both 2.0.0 and 2.0.1.

Note:

 * Moving stdlibs repository location is not a target of this proposal. The implementation details of stdlib gems should hide this from ruby committers.
 * ruby_1_9_3 is not a target of this proposal. The change should be introduced from 2.0.0 release.


...Some more details of the proposal and discussion topics are going to follow as comments.
=end


---Files--------------------------------
5481.pdf (78.2 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>