Unwedge docker build (rexml/strscan issue) #434
Conversation
|
The upstream issues are ruby/rexml#140 In ruby/rexml#140, @kou proposes to pin strscan instead (to the version that is included as a default gem in the Ruby version installed). This is better, as it allows the use of a current rexml, and worse, as it needs to be adjusted each time a new Ruby release updates the version of strscan included as default. Since a new Ruby release happens no more than three or four times a year (and not each of of these will update strscan), and the breakage is obvious (simply stopping the update of the docker image), I'd probably go with his recommendation. The underlying issue is that bundler (reasonably) chooses the most recent revision of a gem, and that may not be the one that is included as a default gem in the ruby version in use -- a compiler run is then needed. A simply The issue is mostly invisible to most maintainers as they are not living under "pure ruby" constraints; the most recent (under certain constraints) revision of a gem is desirable even if it involves native compilation. (This occasionally still comes up as a "Windows issue", because there are additional prerequisites for getting things compiled in Windows.) It seems that Ruby 3.4.0 (scheduled for 2024-12-25) will create a need to mention even default gems in the gem dependencies, so the fact that bundle does not allow to specify being content with the default gem will create a bigger problem with environments limited to pure ruby installations. Again, a simple gem install is unlikely to create problems. |
|
@cabo, thanks. See also https://www.ruby-lang.org/en/news/2024/05/16/dos-rexml-cve-2024-35176/ |
This is a workaround, but it should work for a while.