[ruby-core:107746] [Ruby master Bug#18169] Local copies of gemified libraries are being released out of sync with their gems

Issue #18169 has been updated by headius (Charles Nutter).


This happened again in Ruby 3.1. I have not audited the other gems, but at least securerandom was modified in both repositories but those changes were not released as a new gem.

https://github.com/ruby/securerandom/issues/10

----------------------------------------
Bug #18169: Local copies of gemified libraries are being released out of sync with their gems
https://bugs.ruby-lang.org/issues/18169#change-96671

* Author: headius (Charles Nutter)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
The CRuby codebase includes a number of libraries that have been gemified, more and more with each release. Unfortunately, these libraries are continually out of sync with both their home repositories and their released gems.

The problem lies in the fact that CRuby keeps a local copy of these libraries within the CRuby git repository, and allows committers to make changes either in the CRuby repository or in the gem's home repository. This has led to many releases of Ruby shipping code that **does not correspond to any released version of the related gem**.

I have filed several issues about this but the root cause has not been addressed:

* https://github.com/ruby/ostruct/issues/11
* https://github.com/ruby/matrix/issues/12
* https://github.com/ruby/prime/issues/11
* https://github.com/ruby/webrick/issues/48
* https://github.com/ruby/rdoc/issues/835
* https://github.com/ruby/rexml/issues/79
* https://github.com/ruby/fileutils/issues/59
* https://github.com/ruby/ostruct/issues/31

If these gems are to live on their own as standalone libraries/gems then one of two things must happen:

* All changes to them must go into their repositories. This would be the cleanest option. CRuby would, like JRuby, source these libraries directly from released gems, and no copies of their sources would be versioned in the CRuby git repository.

OR

* CRuby-local changes to these libraries must be prohibited from being released unless there is a corresponding gem release. This would require automated or manual auditing at release time, to ensure that the claimed gem version actually corresponds to the sources being shipped.

In addition to making it impossible for external users of these gems to match CRuby releases, there are more serious implications:

* These hybrid intra-version changes to these libraries cannot be audited to a specific gem release. This could affect stability and security when users attempt to sync their local gem sets to the ones that shipped in a given version of Ruby.
* Security fixes have gone out in CRuby releases but no corresponding x.x.y or x.x.x.y security release of the gem was released. This prevents users from fixing the security issue locally without either upgrading CRuby or also including new functionality changes (which may or may not work on the current version of Ruby).

See the rexml issue above for one example of the security problem. Until the gem was released, it was not possible to install any gem version with the security fix without upgrading functionality elsewhere in rexml.

I believe it is time for CRuby to stop making changes to gemified libraries directly in the CRuby repository. These libraries have their own gems, repositories, and issue trackers, and that is where they should be maintained.



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

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