June 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues
by postmodern (Hal Brodigan) 24 Jul '23

24 Jul '23

Issue #19630 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Feature #19630: [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues https://bugs.ruby-lang.org/issues/19630 * Author: postmodern (Hal Brodigan) * Status: Open * Priority: Normal ---------------------------------------- `Kernel.open()` is the source of numerous [1] security [2] issues [3], due to the fact that it can be used to execute commands if given a String argument of the form `"|command-here"`. However, in most uses of `Kernel.open()` the developer appears to either want to open a local file, or if 'open-uri' was explicitly required open a remote URI. We should deprecate calling `Kernel.open()` with a `"|command-here"` style arguments, with a warning message instructing the developer to use `IO.popen()` instead. Eventually, support for `Kernel.open("|command-here")` could be removed completely, in favor of having the developer explicitly call `IO.popen()` or `URI.open()`. [1]: https://45w1nkv.medium.com/ruby-code-vulnerability-analysis-confirmsnssubsc… [2]: https://bishopfox.com/blog/ruby-vulnerabilities-exploits [3]: https://blog.heroku.com/identifying-ruby-ftp-cve -- https://bugs.ruby-lang.org/

11 18

[ruby-core:111565] [Ruby master Bug#19293] The new Time.new(String) API is nice... but we still need a stricter version of this
by matsuda (Akira Matsuda) 23 Jul '23

23 Jul '23

Issue #19293 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19293: The new Time.new(String) API is nice... but we still need a stricter version of this https://bugs.ruby-lang.org/issues/19293 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-01-01T07:39:00Z master 542e984d82) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The Ruby 3.2 style `Time.new(String)` API works very well so far, but since the original `Time.new(Integer, Integer, Integer...)` API actually accepts String objects as its arguments, there's one ambiguous case as follows: `Time.new('20230123') #=> 20230123-01-01 00:00:00 +0900` Then the problem that I'm facing is that we cannot tell if `Time.new` would parse the given String as ISO8601-ish or just a year, and in order to avoid this ambiguity, we still need to somehow parse the String beforehand in our application side (like we're doing this way in Ruby on Rails https://github.com/rails/rails/blob/c49b8270/activemodel/lib/active_model/t…) then dispatch to the new `Time.new` only when the String is validated to be conforming the ISO format. Otherwise, if we just optimistically pass in given Strings to `Time.new`, we'll occasionally get a Time object with an unintended buggy value. Therefore, it unfortunately seems that my feature request on #16005 still continues... I have to keep proposing that we need either of the following: 1. A trustworthy version of ISO8601 parser method perhaps with another name than `.new` that accepts strict ISO8601-ish String only (but with the T delimiter, I still don't know what the proper name of this format is). 2. Change `Time.new(Integer-ish, Integer-ish, Integer-ish...)` not to accept Integer-ish Strings but to accept only Integers. But I can imagine that this direction is very unlikely acceptable, due to the incompatibility. -- https://bugs.ruby-lang.org/

7 7

[ruby-core:114034] [Ruby master Bug#19748] `String#byteindex` crashes when `offset` is too large
by nobu (Nobuyoshi Nakada) 22 Jul '23

22 Jul '23

Issue #19748 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19748: `String#byteindex` crashes when `offset` is too large https://bugs.ruby-lang.org/issues/19748 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- ```ruby "a".byteindex("", 1000000) #=> [BUG] Segmentation fault ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113160] [Ruby master Bug#19585] Ruby Fails to Build on macOS with --enable-shared and --with-jemalloc
by eviljoel (evil joel) 22 Jul '23

22 Jul '23

Issue #19585 has been reported by eviljoel (evil joel). ---------------------------------------- Bug #19585: Ruby Fails to Build on macOS with --enable-shared and --with-jemalloc https://bugs.ruby-lang.org/issues/19585 * Author: eviljoel (evil joel) * Status: Open * Priority: Normal * ruby -v: 3.2.2, 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby fails to build on macOS 12.6.4 when configured with --enable-shared and --with-jemalloc. I receive the following linking error: ``` building spec/ruby/optional/capi/ext/bignum_spec.bundle Undefined symbols for architecture x86_64: "_je_free", referenced from: _bignum_spec_rb_big_pack_array in bignum_spec-f7dc36.o "_je_malloc", referenced from: _bignum_spec_rb_big_pack_array in bignum_spec-f7dc36.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [spec/ruby/optional/capi/ext/bignum_spec.bundle] Error 1 ``` It appears that the bignum C API spec requires "-undefined dynamic_lookup" to be enabled. I can get the build to succeed with: ``` ./configure --enable-shared --with-jemalloc DLDFLAGS='-Wl,-undefined,dynamic_lookup' ``` I’ve created several bash scripts to demonstrate that: 1) This is an error with the current production release of Ruby. Running jemallocBug-ruby3.2.2-20230407.sh demonstrates that building Ruby with these parameters fails in Ruby 3.2.2. 2) This is a regression in at least the Ruby 3.1 branch. Running jemallocSucceeds-ruby3.1.2-20230407.sh demonstrates that building Ruby with these parameters worked with Ruby 3.1.2 and running jemallocBug-ruby3.1.3-20230407.sh demonstrates that building Ruby with these parameters fails in Ruby 3.1.3. In the Ruby 3.1 branch, the first commit where this broke appears to be 2244fc9aa7ef8e03ac966e59b581baa021106b46. ld version information: ``` $ ld -v @(#)PROGRAM:ld PROJECT:ld64-820.1 BUILD 20:07:01 Nov 7 2022 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 14.0.0, (clang-1400.0.29.202) (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) $ ``` clang version information: ``` $ clang -v Apple clang version 14.0.0 (clang-1400.0.29.202) Target: x86_64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin $ ``` I’m using jemalloc version 5.3.0. MacBook Specs are: ``` Model: MacBook Pro (16-inch, 2019) Processor: 2.4 GHz 8-Core Intel Core i9 Memory: 32 GB 2667 MHz DDR4 Graphics: AMD Radeon Pro 5300M 4 GB and Intel UHD Graphics 630 1536 MB ``` I’ve attached the config.log and config.status for the failed Ruby 3.2.2 build. Please let me know if you need any more information. ---Files-------------------------------- jemallocSucceeds-ruby3.1.2-20230407.sh (804 Bytes) jemallocBug-ruby3.2.2-20230407.sh (804 Bytes) jemallocBug-ruby3.1.3-20230407.sh (804 Bytes) ruby-3.2.2-config.status (34.4 KB) ruby-3.2.2-config.log (1.57 MB) -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112918] [Ruby master Bug#19532] Handling of 6-byte codepoints in left_adjust_char_head in CESU-8 encoding is broken
by Eregon (Benoit Daloze) 22 Jul '23

22 Jul '23

Issue #19532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19532: Handling of 6-byte codepoints in left_adjust_char_head in CESU-8 encoding is broken https://bugs.ruby-lang.org/issues/19532 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Fix in https://github.com/ruby/ruby/pull/7510 -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114031] [Ruby master Bug#19746] `String#index` with regexp and too large offset doesn't clear `$~`
by nobu (Nobuyoshi Nakada) 22 Jul '23

22 Jul '23

Issue #19746 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19746: `String#index` with regexp and too large offset doesn't clear `$~` https://bugs.ruby-lang.org/issues/19746 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ```ruby /./ =~ "a" p "x".index(/0/, 4) #=> nil p $~ #=> #<MatchData "a"> ``` while `rindex` does. ```ruby /./ =~ "a" p "x".rindex(/0/, 4) #=> nil p $~ #=> nil ``` It seems since 1.9. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112926] [Ruby master Misc#19535] Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID`
by byroot (Jean Boussier) 22 Jul '23

22 Jul '23

Issue #19535 has been reported by byroot (Jean Boussier). ---------------------------------------- Misc #19535: Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID` https://bugs.ruby-lang.org/issues/19535 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context I've been helping the Mastodon folks in investigating a weird Marshal deserialization bug they randomly experience since they upgraded to Ruby 3.2: https://github.com/mastodon/mastodon/issues/23644 Ultimately the bug comes from a circular dependency issues in the object graph that is serialized when one call `Marshal.dump` on an `ActiveRecord::Base` object. A simplified reproduction to better explain the problem is: ```ruby class Status def normal_order @attributes = { id: 42 } @relations = { self => 1 } self end def inverse_order @relations = nil @attributes = { id: 42 } @relations = { self => 1 } self end def hash @attributes.fetch(:id) end end s = Marshal.load(Marshal.dump(Status.new.normal_order)) s = Marshal.load(Marshal.dump(Status.new.inverse_order)) ``` In short, that `Status` object is both the top level object, and is referenced as a key in a hash, in that same payload. It also defined a custom `#hash` method, that requires some other attribute to be set. It all "works" as long as `@attributes` is dumped before `@relations`. ### Problem The above micro-reproduction uses two different shapes to demonstrate the ordering issues, but in both case the ordering is predictable. However if you generate too many shapes from a single class, it will be marked as `TOO_COMPLEX` and future instance will have their instance variables backed by an `id_table`, which is unordered, and will cause a similar issue. I definitely consider this a bug on the Rails side, and I will do what I can so that Rails doesn't depend on that implicit ordering. However it's unlikely we'll be able to fix older version, and other users may run into this issue when upgrading to Ruby 3.2, so I think it may be worth to try to preserve some sort of predicable ordering, at least for a few more versions. Additionally, debugging it was made particularly difficult, because it would work fine initially, and then break after enough shapes had been generated. Generally speaking I think such semi-predictable behavior is much worse than a fully random behavior (similar to how Go randomize keys order in their maps). ### Historical behavior On Ruby 3.1 and older, the instance variables ordering was defined by the order in which each ivar appeared for the very first time: ```ruby class Foo def set @a = 1 @b = 2 @c = 3 self end def inverse_order @c = 3 @b = 2 @a = 1 self end end p Foo.new.set.instance_variables # => [:@a, :@b, :@c] p Foo.new.inverse_order.instance_variables # => [:@a, :@b, :@c] ``` This means that the order could be different from once execution of the program to another, but would remain stable inside a single process. On 3.2, it's now defined by the order in which each ivar appeared in that specific object instance: ```ruby [:@a, :@b, :@c] [:@c, :@b, :@a] ``` Except, if the object is backed by an `id_table`, in which case it's fully unpredictable. ### Possible changes I discussed this with @tenderlovemaking, and he suggested we could change the `id_table` for an `st_table` so that the ordering could be predictable again, and would behave like objects with a non-complex shape. Another possibility would be to preserve the observable behavior of 3.1 and older. Or of course we could clearly specify that the ordering is random, but if so I think it would be wise to make it always random so that this class of bugs has a much higher chance to be caught early in testing rather than in production. cc @Eregon as I presume this has implications on TruffleRuby as well. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:113482] [Ruby master Bug#19640] `IO#puts` can generate zero length iov which can cause rb_bug crash.
by ioquatix (Samuel Williams) 22 Jul '23

22 Jul '23

Issue #19640 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19640: `IO#puts` can generate zero length iov which can cause rb_bug crash. https://bugs.ruby-lang.org/issues/19640 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED ---------------------------------------- In the fiber scheduler, `IO#puts ""` or `IO#puts nil` can generate a zero length `iov` which causes `io_binwritev_internal` to fail since the result is zero. We need to fix `IO#puts` so that it does not generate zero length writes, but also we fix `io_binwritev_internal` to handle this case more robustly. Fix: https://github.com/ruby/ruby/pull/7806/files -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113745] [Ruby master Bug#19709] `Thread.join(timeout)` hangs in fiber scheduler.
by ioquatix (Samuel Williams) 22 Jul '23

22 Jul '23

Issue #19709 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19709: `Thread.join(timeout)` hangs in fiber scheduler. https://bugs.ruby-lang.org/issues/19709 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Unfortunately the following script can hang: ```ruby require_relative 'test/fiber/scheduler' scheduler = Scheduler.new Fiber.set_scheduler scheduler Fiber.schedule do thread = Thread.new{sleep} thread.join(0.1) end ``` The termination condition in the `thread_join` is not expressed correctly. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113977] [Ruby master Bug#19743] Ruby's parser seems to ignoring DOT at the end of file just after digits
by tompng (tomoya ishida) 22 Jul '23

22 Jul '23

Issue #19743 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19743: Ruby's parser seems to ignoring DOT at the end of file just after digits https://bugs.ruby-lang.org/issues/19743 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-06-19T09:28:10Z master 2a80bac9f0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I expect all to be syntax error ~~~ruby eval "puts 1." #=> 1 eval "puts 1. " #=> syntax error eval "puts 1.\n" #=> syntax error ~~~ For ripper, period token is missing ~~~ruby Ripper.tokenize("1.") #=> ["1"] Ripper.tokenize("1. ") #=> ["1", ".", " "] ~~~ -- https://bugs.ruby-lang.org/

3 2