October 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 18 Oct '25

18 Oct '25

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

6 12

[ruby-core:123446] [Ruby Bug#21632] Backport REXML CVE-2025-58767 fix
by Bo98 (Bo Anderson) 16 Oct '25

16 Oct '25

Issue #21632 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #21632: Backport REXML CVE-2025-58767 fix https://bugs.ruby-lang.org/issues/21632 * Author: Bo98 (Bo Anderson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Even though it's a bundled gem and not a default gem, it would be worthwhile backporting the fix for CVE-2025-58767 (https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/) Ruby 3.4 PR: https://github.com/ruby/ruby/pull/14795 Ruby 3.3 PR: https://github.com/ruby/ruby/pull/14796 I'm not sure what to do for Ruby 3.2. It's a security fix so it qualifies for a backport, but there's other changes included in a version bump. Do we need a rexml 3.3.9.1? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123489] [Ruby Bug#21641] Hash#to_s behaves different in 3.4
by matheussilvasantos (Matheus Oliveira) 16 Oct '25

16 Oct '25

Issue #21641 has been reported by matheussilvasantos (Matheus Oliveira). ---------------------------------------- Bug #21641: Hash#to_s behaves different in 3.4 https://bugs.ruby-lang.org/issues/21641 * Author: matheussilvasantos (Matheus Oliveira) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I couldn't find anywhere documenting this change from Ruby 3.3 to Ruby 3.4: 3.3.9: ``` ruby > irb 3.3.9 :001 > {x:1}.to_s => "{:x=>1}" 3.3.9 :002 > ``` 3.4.0: ```ruby 3.4.0 :001 > {x:1}.to_s => "{x: 1}" 3.4.0 :002 > ``` Is there a way to continue with the old behaviour - flag to compilation, monkey patch, etc.? Unfortunately, the application I'm working on stores the `to_s` in Redis and use it later; if the result doesn't match for the same Hash, it would break a few things. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123482] [Ruby Misc#21639] Guidelines or documentation for porting Ruby to a new platform (z/OS)
by sachin.t＠ibm.com (Sachin T) 15 Oct '25

15 Oct '25

Issue #21639 has been reported by sachin.t(a)ibm.com (Sachin T). ---------------------------------------- Misc #21639: Guidelines or documentation for porting Ruby to a new platform (z/OS) https://bugs.ruby-lang.org/issues/21639 * Author: sachin.t(a)ibm.com (Sachin T) * Status: Open ---------------------------------------- Hi Ruby team, I work on the IBM z/OS platform and am currently working on porting Ruby to it. I wanted to ask whether there are any existing porting guidelines, documentation, or recommended steps for bringing Ruby up on a new platform. Current status: I’ve successfully started building Ruby using the standard ./configure && make flow. RJIT/YJIT are disabled, but miniruby currently exits silently with no output (miniruby -v). If there are any references, platform-porting checklists, or recommended practices for handling platform-specific code (especially around TLS, signal handling, and miniruby bring-up), it would be really helpful. Thanks in advance for your guidance. Best regards, Sachin -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 11 Oct '25

11 Oct '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:123445] [Ruby Bug#21631] Backport openssl gem bugfix releases
by Bo98 (Bo Anderson) 11 Oct '25

11 Oct '25

Issue #21631 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #21631: Backport openssl gem bugfix releases https://bugs.ruby-lang.org/issues/21631 * Author: Bo98 (Bo Anderson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The openssl gem has made new patch releases for all supported release lines in order to fix a compatibility issue with OpenSSL 3.6.0 (along with other bug fixes such as one for a segfault). Without the compatibility fix, the openssl gem is largely broken for certificate verification with OpenSSL 3.6.0, which then affects other parts of Ruby like net-http. Ruby 3.4 PR (3.3.0 -> 3.3.1): https://github.com/ruby/ruby/pull/14792 Ruby 3.3 PR (3.2.0 -> 3.2.2): https://github.com/ruby/ruby/pull/14793 I'm not entirely sure what to do for Ruby 3.2. We can update the gem from 3.1.0 to 3.1.2 but that's perhaps out-of-scope for Ruby 3.2 being in security maintenance mode. Would cherry-picking the single compatibility fix commit be acceptable? The issue has been widely noticed already: https://github.com/ruby/openssl/issues/949 -- https://bugs.ruby-lang.org/

4 6

[ruby-core:123464] [Ruby Bug#21635] Reading code from STDIN unexpectedly sets $_ in 3.4.6+
by sisyphus (Sisyphus P) 10 Oct '25

10 Oct '25

Issue #21635 has been reported by sisyphus (Sisyphus P). ---------------------------------------- Bug #21635: Reading code from STDIN unexpectedly sets $_ in 3.4.6+ https://bugs.ruby-lang.org/issues/21635 * Author: sisyphus (Sisyphus P) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- It seems from Ruby 3.4.6+ if you pass in code that doesn't end with a newline to the ruby interpreter it sets `$_`: ``` # ruby -v ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [arm64-darwin23] # printf 'p $_' | ruby "p $_" ``` This only happens if the code passed in doesn't end with a newline and doesn't happen in ruby 3.4.5 or earlier: ``` # ruby -v ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin23] # printf 'p $_' | ruby nil ``` I would expect that `$_` is nil at the start of program execution. NB. this does result in the world's shortest Ruby quine (`printf 'print' | ruby`) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123463] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0

[ruby-core:123462] PAY OR BE EXPOSED ❗️
by Ruby-core 10 Oct '25

10 Oct '25

1 0

[ruby-core:123460] PAY OR BE EXPOSED ❗️
by Ruby-core 09 Oct '25

09 Oct '25

1 0