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

[ruby-core:113926] [Ruby master Bug#19735] Add support for UUID version 7
by nevans (Nicholas Evans) 19 Sep '23

19 Sep '23

Issue #19735 has been reported by nevans (Nicholas Evans). ---------------------------------------- Bug #19735: Add support for UUID version 7 https://bugs.ruby-lang.org/issues/19735 * Author: nevans (Nicholas Evans) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Although the specification for UUIDv7 is still in draft, the UUIDv7 algorithm has been stable as the RFC progresses to completion. Version 7 UUIDs can be very useful, because they are lexographically sortable, which can improve e.g: database index locality. See section 6.10 of the draft specification for further explanation: https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-06.html ```ruby require 'random/formatter' Random.uuid_v7 # => "0188ca50-fcc0-7881-b5c5-6d55cd8fc373" Random.uuid_v7 # => "0188ca51-0069-7304-be2e-0c3cd908789b" Random.uuid_v7 # => "0188ca51-04aa-7b57-a6ec-c49573412a9d" Random.uuid_v7 # => "0188ca51-0853-7979-ae37-485460e9f4f1" # or prng = Random.new prng.uuid_v7 # => "0188ca51-5e72-7950-a11d-def7ff977c98" ``` PR here: https://github.com/ruby/ruby/pull/7953 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:113819] [Ruby master Feature#19720] Warning for non-linear Regexps
by Eregon (Benoit Daloze) 14 Sep '23

14 Sep '23

Issue #19720 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #19720: Warning for non-linear Regexps https://bugs.ruby-lang.org/issues/19720 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- I believe the best way to solve ReDoS is to ensure all Regexps used in the process are linear. Using `Regexp.timeout = 5.0` or so does not really prevent ReDoS, given enough requests causing that timeout the servers will still be very unresponsive. To this purpose, we should make it easy to identify non-linear Regexps and fix them. I suggest we either use 1. a performance warning (enabled with `Warning[:performance] = true`, #19538) or 2. a new regexp warning category (enabled with `Warning[:regexp] = true`). I think we should warn only once per non-linear Regexp, to avoid too many such warnings. We could warn as soon as the Regexp is created, or on first match. On first match might makes more sense for Ruby implementations which compile the Regexp lazily (since that is costly during startup), and also avoids warning for Regexps which are never used (which can be good or bad). OTOH, if the warning is enabled, we could always compile the Regexp eagerly (or at least checks whether it's linear), and that would then provide a better way to guarantee that all Regexps created so far are linear. Because warnings are easily customizable, it is also possible to e.g. `raise/abort` on such a warning, if one wants to ensure their application does not use a non-linear Regexp and so cannot be vulnerable to ReDoS: ```ruby Warning.extend Module.new { def warn(message, category: nil, **) raise message if category == :regexp super end } ``` A regexp warning category seems better for that as it makes it easy to filter by category, if a performance warning one would need to match the message which is less clean. As a note, TruffleRuby already has a similar warning, as a command-line option: ``` $ truffleruby --experimental-options --warn-truffle-regex-compile-fallback -e 'Gem' truffleruby-dev/lib/mri/rubygems/version.rb:176: warning: Regexp /\A\s*([0-9]+(?>\.[0-9a-zA-Z]+)*(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?)?\s*\z/ at_start=false encoding=US-ASCII requires backtracking and will not match in linear time truffleruby-dev/lib/mri/rubygems/requirement.rb:105: warning: Regexp /\A\s*(=|!=|>|<|>=|<=|~>)?\s*([0-9]+(?>\.[0-9a-zA-Z]+)*(-[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?)\s*\z/ at_start=false encoding=US-ASCII requires backtracking and will not match in linear time ``` So the warning message could be like `FILE:LINE: warning: Regexp /REGEXP/ requires backtracking and might not match in linear time and might cause ReDoS` or more concise: `FILE:LINE: warning: Regexp /REGEXP/ requires backtracking and might cause ReDoS` -- https://bugs.ruby-lang.org/

5 10

[ruby-core:114501] [Ruby master Bug#19849] Requiring file with autoload results in confusing error if file doesn't exist
by p8 (Petrik de Heus) 14 Sep '23

14 Sep '23

Issue #19849 has been reported by p8 (Petrik de Heus). ---------------------------------------- Bug #19849: Requiring file with autoload results in confusing error if file doesn't exist https://bugs.ruby-lang.org/issues/19849 * Author: p8 (Petrik de Heus) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Given the following file: ```ruby # example.rb require_relative 'autoload_example.rb' Example.new ``` and the constant `Example` is defined using autoload, with an unknown path: ```ruby # autoload_example.rb autoload "Example", "path_unknown" ``` Running `ruby example.rb` results in the following error: ``` <internal:~/.rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- path_unknown (LoadError) from <internal:~/.rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from example.rb:1:in `<main>' ``` The error is somewhat confusing as it doesn't show the location of the `autoload` which caused the error. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:114517] [Ruby master Bug#19850] Get thread creation time
by ngan (Ngan Pham) 14 Sep '23

14 Sep '23

Issue #19850 has been reported by ngan (Ngan Pham). ---------------------------------------- Bug #19850: Get thread creation time https://bugs.ruby-lang.org/issues/19850 * Author: ngan (Ngan Pham) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I was debugging some threads hanging issue and thought it would be nice to know how long a thread has been around for. Would there be interest in a `Thread#creation_time` (or some other name) that returns the time when the thread was created? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114348] [Ruby master Feature#19832] Method#destructive?, UnboundMethod#destructive?
by sawa (Tsuyoshi Sawada) 14 Sep '23

14 Sep '23

Issue #19832 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #19832: Method#destructive?, UnboundMethod#destructive? https://bugs.ruby-lang.org/issues/19832 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- I propose to add `destructive?` property to `Method` and `UnboundMethod` instances, which shall behave like: ```ruby String.instance_method(:<<).destructive? # => true String.instance_method(:+).destructive? # => false ``` One main purpose of using these classes is to inspect and make sure how a certain method behaves. Besides arity and owner, whether a method is destructive or not is one important piece of information, but currently, you cannot achieve that from `Method` or `UnboundMethod` instances. -- https://bugs.ruby-lang.org/

9 14

[ruby-core:114600] [Ruby master Misc#19858] DevMeeting-2023-09-14
by mame (Yusuke Endoh) 13 Sep '23

13 Sep '23

Issue #19858 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19858: DevMeeting-2023-09-14 https://bugs.ruby-lang.org/issues/19858 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/09/14 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/09/11. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:113944] [Ruby master Feature#19737] Add `IO::Buffer#cat` for concat `IO::Buffer` instances
by unasuke (Yusuke Nakamura) 12 Sep '23

12 Sep '23

Issue #19737 has been reported by unasuke (Yusuke Nakamura). ---------------------------------------- Feature #19737: Add `IO::Buffer#cat` for concat `IO::Buffer` instances https://bugs.ruby-lang.org/issues/19737 * Author: unasuke (Yusuke Nakamura) * Status: Open * Priority: Normal ---------------------------------------- ## motivation In my use case, I want to concat two IO::Buffer instances. But current implementation doesn't have that way. Then I created a patch. Opend here: TBD ## concern I have two concerns about it. ### 1. Should we provide `IO::Buffer#+` as an alias? In String instance, `"a" + "b"` returns `"ab",`. It feels intuitive. So, should we provide the same way as `IO::Buffer.for("a") + IO::Buffer.for("b")`? If `+` is provided, I naturally assume that `*` is also provided as an operator. Should we also provide an `IO::Buffer#*` method for symmetry with the String class? I thought the behavior of the "*" method is not obvious to me... (Is it right to just return joined buffers?) ### 2. Should it accept multiple IO::Buffer instances? In the `cat` command, it accepts multiple inputs like this. ``` $ cat a.txt b.txt c.txt a b c ``` Should `IO::Buffer#cat` accept multiple inputs too? -- https://bugs.ruby-lang.org/

4 6

[ruby-core:114319] [Ruby master Feature#19790] Optionally write Ruby crash reports into a file rather than STDERR
by byroot (Jean Boussier) 12 Sep '23

12 Sep '23

Issue #19790 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19790: Optionally write Ruby crash reports into a file rather than STDERR https://bugs.ruby-lang.org/issues/19790 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Use case On our servers we set [`/proc/sys/kernel/core_pattern`](https://man7.org/linux/man-pages/man5/core.5.html) to point to a small utility that report all the crashes happening in production with the associated core dump into BugSnag. This allowed us to find and fix many Ruby and native extensions bugs in the last few years. However, these are hard to triage, so we'd like to augment these crash reports with the output of `rb_vm_bugreport()`. ### Problem `rb_vm_bugreport()` is hard coded to print to STDERR, this makes it hard to extract and parse the report in a production environment, as very often STDERR is shared with other processes, so the crash report is intertwined with logs from other processes. ### Feature Request It would be very useful if Ruby could write the crash report to an arbitrary path rather than STDERR, akin to `kernel/core_pattern`. Especially it would be useful if it supported interpolating the crashing process PID with `%p` like `kernel/core_pattern`, as it would make it easier to map that report with the core file. This could be controller by an environment variable such as `RUBY_BUGREPORT_PATH`. e.g. ``` RUBY_BUGREPORT_PATH=/var/log/ruby/ruby-crash-pid-%p.log ``` ### Optional Features `kernel/core_pattern` supports other interpolations, however not all of them would make sense for Ruby to support. %% A single % character. %c Core file size soft resource limit of crashing process (since Linux 2.6.24). %d Dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7). %e The process or thread's comm value, which typically is the same as the executable filename (without path prefix, and truncated to a maximum of 15 characters), but may have been modified to be something different; see the discussion of /proc/pid/comm and /proc/pid/task/tid/comm in proc(5). %E Pathname of executable, with slashes ('/') replaced by exclamation marks ('!') (since Linux 3.0). %g Numeric real GID of dumped process. %h Hostname (same as nodename returned by uname(2)). %i TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18). %I TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18). %p PID of dumped process, as seen in the PID namespace in which the process resides. %P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12). %s Number of signal causing dump. %t Time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). %u Numeric real UID of dumped process. Additionally, if `kernel/core_pattern` starts with a pipe (`|`), then it allows to pipe the core dump to another program, this may also make sense as a feature. ### Prior Art Aside from `kernel/core_pattern`, some other virtual machine have a similar feature, for instance the JVM has a configurable crash report: ``` -XX:ErrorFile=/var/log/java/hs_err_pid%p.log ``` -- https://bugs.ruby-lang.org/

5 12

[ruby-core:114446] [Ruby master Bug#19844] Ruby 3.2 fails to build with openssl version 3
by narine_moss＠yahoo.com (Narine Mossikyan) 12 Sep '23

12 Sep '23

Issue #19844 has been reported by narine_moss(a)yahoo.com (Narine Mossikyan). ---------------------------------------- Bug #19844: Ruby 3.2 fails to build with openssl version 3 https://bugs.ruby-lang.org/issues/19844 * Author: narine_moss(a)yahoo.com (Narine Mossikyan) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby version 3.2 code base: https://github.com/ruby/ruby/tree/1c7624469880bcb964be09a49e4907873f45b026 openssl v3 is installed under /usr/local_ssl_3.0.0. ./configure --with-openssl-dir=/usr/local_ssl_3.0.0 I get the following error when running make: openssl_missing.c:24:13: error: dereferencing pointer to incomplete type ‘X509_CRL {aka const struct X509_crl_st}’ *psig = crl->signature; ^~ openssl_missing.c: In function ‘ossl_X509_REQ_get0_signature’: openssl_missing.c:36:13: error: dereferencing pointer to incomplete type ‘X509_REQ {aka const struct X509_req_st}’ *psig = req->signature; ^~ I am trying to build ruby 3.2 with openssl version 3 to install it on ubuntu 22 that only has openssl v3. Can you advise me how to configure ruby to bypass this error? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114310] [Ruby master Bug#19788] Ripper returns a symbol instead of a token as operator for "::"
by thyresias (Thierry Lambert) 09 Sep '23

09 Sep '23

Issue #19788 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #19788: Ripper returns a symbol instead of a token as operator for "::" https://bugs.ruby-lang.org/issues/19788 * Author: thyresias (Thierry Lambert) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby require 'ripper' class BasicParser < Ripper EVENTS.each do |event| module_eval(<<~RUBY, __FILE__, __LINE__ + 1) def on_#{event}(*args) puts "#{event}(\#{args.inspect})" args.unshift :#{event} args end RUBY end end require 'pp' BasicParser.new('a&.b').parse # in stdout: # ident(["a"]) # op(["&."]) # vcall([[:ident, "a"]]) # ident(["b"]) # call([[:vcall, [:ident, "a"]], [:op, "&."], [:ident, "b"]]) BasicParser.new('a::b').parse # in stdout: # ident(["a"]) # op(["::"]) # vcall([[:ident, "a"]]) # ident(["b"]) # call([[:vcall, [:ident, "a"]], :"::", [:ident, "b"]]) ``` On the last line, consistent with `&.`, I would have expected: ```ruby # call([[:vcall, [:ident, "a"]], [:op, "::"], [:ident, "b"]]) ``` This is true for the "operator" argument of `call`, `command_call` and `field`. Is it intended? -- https://bugs.ruby-lang.org/

4 3