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

[ruby-core:118230] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by shyouhei (Shyouhei Urabe) 07 Jun '24

07 Jun '24

Issue #6648 has been updated by shyouhei (Shyouhei Urabe). In short the problem we see is feeding strings from untrusted sources to generic `Kernel#exec`. Sounds ultra risky, no? Let's not do so. If what is needed is just launching a ruby process, we could perhaps design a workaround. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108725 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118150] [Ruby master Bug#20520] _FORTIFY_SOURCE=3 is not correctly respected
by vo.x (Vit Ondruch) 07 Jun '24

07 Jun '24

Issue #20520 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20520: _FORTIFY_SOURCE=3 is not correctly respected https://bugs.ruby-lang.org/issues/20520 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [aarch64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In Fedora, we are using following compilation options: ~~~ + CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' ~~~ Please note that as of recently, there is included `_FORTIFY_SOURCE=3`. The problem is, that Ruby doing its configuration check: ~~~ checking whether -O3 -D_FORTIFY_SOURCE=2 is accepted as CFLAGS... yes ~~~ Includes another variant of `_FORTIFY_SOURCE=2` into `XFLAGS`: ~~~ $ /usr/bin/make -O -j12 V=1 VERBOSE=1 'COPY=cp -p' -C redhat-linux-build make: Entering directory '/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/redhat-linux-build' BASERUBY = /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/tool/missing-baseruby.bat CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -mbranch-protection=standard -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/aarch64-linux -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/enc/unicode/15.0.0 CPPFLAGS = DLDFLAGS = -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-soname,libruby.so.3.3 -fstack-protector-strong SOLIBS = -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lpthread LANG = C.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = -j12 -Otarget --jobserver-auth=fifo:/tmp/GMfifo10279 --sync-mutex=fnm:/tmp/GmbGoenG RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/redhat-linux-build/yjit/target/release/' /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/yjit/src/lib.rs gcc (GCC) 14.1.1 20240522 (Red Hat 14.1.1-4) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. make: Leaving directory '/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/redhat-linux-build' make: Entering directory '/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/redhat-linux-build' gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -mbranch-protection=standard -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/aarch64-linux -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/include -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1 -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/prism -I/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/enc/unicode/15.0.0 -o dmyext.o -c /builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/dmyext.c ... snip ... ~~~ -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115595] [Ruby master Bug#20043] `defined?` checks for method existence but only sometimes
by tenderlovemaking (Aaron Patterson) 07 Jun '24

07 Jun '24

Issue #20043 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20043: `defined?` checks for method existence but only sometimes https://bugs.ruby-lang.org/issues/20043 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-05T21:25:34Z master 56eccb350b) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When an expression is passed to `defined?`, it will _sometimes_ check if a method in a sub-expression is defined and sometimes it won't. For example: ``` $ ./miniruby -e'p defined?(a)' nil $ ./miniruby -e'p defined?([a])' nil ``` In the above case, Ruby will check whether or not the method `a` is defined, and it returns `nil`. However, if you use a splat, it will not check: ``` $ ./miniruby -e'p defined?([*a])' "expression" ``` The same thing seems to happen with method parameters: ``` $ ./miniruby -e'p defined?(itself)' "method" $ ./miniruby -e'p defined?(itself(a))' nil $ ./miniruby -e'p defined?(itself(*a))' "method" ``` Oddly, `defined?` will check contents of arrays, but _won't_ check contents of hashes: ``` $ ./miniruby -e'p defined?([[[[a]]]])' nil $ ./miniruby -e'p defined?({ a => a })' "expression" ``` I think all of the cases that refer to `a` should check whether or not `a` is defined regardless of splats or hashes. -- https://bugs.ruby-lang.org/

7 9

[ruby-core:118223] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by shyouhei (Shyouhei Urabe) 07 Jun '24

07 Jun '24

Issue #6648 has been updated by shyouhei (Shyouhei Urabe). Eregon (Benoit Daloze) wrote in #note-24: > @mame CRuby already needs to get arguments as an array to parse command-line flags, so `RbConfig.ruby_args` just exposes that. > If CRuby can parse these Ruby command-line flags, for sure we can save them in some kind of array. This is true. Technically we can provide such array. But for what reason? The question is its usage. > IIRC these extra complications are only relevant in `.bat` files, the C main still receives an array of arguments on Windows. Background: This is how we execute external process in Windows: https://github.com/ruby/ruby/blob/029d92b8988d26955d0622f0cbb8ef3213200749/… Also background: Windows API for creating a process: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-pr… So this is not about receiving arguments but calling a process. As you see there is no Windows API that takes `char**`. We cannot safely pass through what we have. You have to concatenate them into one argument string (`LPWSTR lpCommandLine`), with proper escaping of whitespace etc. This is where the security concern arises. Because process arguments come from out of the process itself by nature, there is no guarantee that they are written by good will. I have to say it is at least dangerous to "escape" them to be "safe" to pass to a process invoking API. Our current implementation is not ready for that... Is it even possible? ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108715 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118184] [Ruby master Bug#20527] Control-Flow protection cannot be enabled for Ruby due to ASM bits
by vo.x (Vit Ondruch) 06 Jun '24

06 Jun '24

Issue #20527 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20527: Control-Flow protection cannot be enabled for Ruby due to ASM bits https://bugs.ruby-lang.org/issues/20527 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Checking if Ruby is properly hardened up to Fedora standard using `annocheck`, this is the result: ~~~ $ annocheck redhat-linux-build/libruby.so.3.3.1 annocheck: Version 12.54. Hardened: libruby.so.3.3.1: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags Hardened: libruby.so.3.3.1: FAIL: property-note test because a property note was found but it shows that cf-protection is not enabled Hardened: Rerun annocheck with --verbose to see more information on the tests. Hardened: libruby.so.3.3.1: Overall: FAIL. ~~~ Wondering what is the issue, I have executed following: ~~~ $ annocheck redhat-linux-build/* 2>/dev/null | grep FAIL | less Hardened: Context.o: Overall: FAIL (due to MAYB results). Hardened: libruby-static.a:Context.o: Overall: FAIL (due to MAYB results). Hardened: libruby.so.3.3.1: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags Hardened: libruby.so.3.3.1: FAIL: property-note test because a property note was found but it shows that cf-protection is not enabled Hardened: libruby.so.3.3.1: Overall: FAIL. Hardened: miniruby: FAIL: cf-protection test because .note.gnu.property section did not contain the necessary flags Hardened: miniruby: FAIL: property-note test because a property note was found but it shows that cf-protection is not enabled Hardened: miniruby: Overall: FAIL. ~~~ This suggest that the `Context.o` is the culprit. Lets take a detailed look: ~~~ $ annocheck redhat-linux-build/coroutine/amd64/Context.o --verbose annocheck: Version 12.54. Hardened: redhat-linux-build/coroutine/amd64/Context.o: info: No matching profile found. Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: pie test because the ELF file header has the correct type Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: gnu-stack test because non-executable .note.GNU-stack section found Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: gaps test because no notes found - therefore there are no gaps! Hardened: redhat-linux-build/coroutine/amd64/Context.o: MAYB: test: notes, reason: notes not found and no DWARF info found (could there be a separate debuginfo file ?) Hardened: redhat-linux-build/coroutine/amd64/Context.o: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-notes.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: bind-now test because only needed for executables Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: branch-protection test because not an AArch64 binary Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: cf-protection test because not an x86_64 executable Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: dynamic-segment test Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: dynamic-tags test because AArch64 specific Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: entry test Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: fast test Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: fips test because not a GO binary Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: fortify test because no compiled C/C++ code found Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: glibcxx-assertions test because no compiled C/C++ code found Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: gnu-relro test because not needed in object files Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: go-revision test because no GO compiled code found Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: implicit-values test because These tests are only relevent to C source code Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: instrumentation test Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: lto test because not compiled from C/C++ code Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: openssl-engine test Hardened: redhat-linux-build/coroutine/amd64/Context.o: MAYB: test: optimization, reason: could not determine how the code was created Hardened: redhat-linux-build/coroutine/amd64/Context.o: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-optimization.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: This can happen if the program is compiled from a language unknown to annocheck Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: or because there are no annobin build notes (could they be in a separate file ?) Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: For more details see https://sourceware.org/annobin/annobin.html/Absence-of-compiled-code.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: MAYB: test: pic, reason: no valid notes found regarding this test Hardened: redhat-linux-build/coroutine/amd64/Context.o: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-pic.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: production test Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: property-note test because property notes not needed in object files Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: run-path test Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: rwx-seg test Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: short-enums test Hardened: redhat-linux-build/coroutine/amd64/Context.o: MAYB: test: stack-clash, reason: could not determine how the code was created Hardened: redhat-linux-build/coroutine/amd64/Context.o: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-stack-clash.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: This can happen if the program is compiled from a language unknown to annocheck Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: or because there are no annobin build notes (could they be in a separate file ?) Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: For more details see https://sourceware.org/annobin/annobin.html/Absence-of-compiled-code.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: MAYB: test: stack-prot, reason: could not determine how the code was created Hardened: redhat-linux-build/coroutine/amd64/Context.o: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-stack-prot.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: This can happen if the program is compiled from a language unknown to annocheck Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: or because there are no annobin build notes (could they be in a separate file ?) Hardened: redhat-linux-build/coroutine/amd64/Context.o: WARN: For more details see https://sourceware.org/annobin/annobin.html/Absence-of-compiled-code.html Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: stack-realign test because not an i686 executable Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: textrel test Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: threads test Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: unicode test Hardened: redhat-linux-build/coroutine/amd64/Context.o: skip: warnings test because no compiled C/C++ code found Hardened: redhat-linux-build/coroutine/amd64/Context.o: PASS: writable-got test Hardened: redhat-linux-build/coroutine/amd64/Context.o: Overall: FAIL (due to MAYB results). ~~~ Well, `skip: cf-protection test because not an x86_64 executable` is not really helpful, therefore I have opened ticket with annocheck folks [1], where they suggest to update the `Context.S` according to the following guidelines: https://sourceware.org/annobin/annobin.html/Test-cf-protection.html P.S. With YJIT enabled, there is also issue with the Rust code, therefore I have tested this with YJIT disabled and without Rust available in the environment. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2284605 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118216] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Eregon (Benoit Daloze) 06 Jun '24

06 Jun '24

Issue #6648 has been updated by Eregon (Benoit Daloze). @mame CRuby already needs to get arguments as an array to parse command-line flags, so `RbConfig.ruby_args` just exposes that. If CRuby can parse these Ruby command-line flags, for sure we can save them in some kind of array. IIRC these extra complications are only relevant in `.bat` files, the C main still receives an array of arguments on Windows. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108705 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117866] [Ruby master Misc#20488] Document source file size restrictions
by kddnewton (Kevin Newton) 06 Jun '24

06 Jun '24

Issue #20488 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20488: Document source file size restrictions https://bugs.ruby-lang.org/issues/20488 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I was hoping we might be able to decide on an official maximum size for a source file in terms of bytes/lines/columns/etc. Ruby uses fixed integer sizes to represent line numbers, column numbers, offsets, etc. These can overflow with files that are too big. Sometimes they will fail with cryptic messages like: ``` ruby: negative string size (or size too big) (ArgumentError) ``` (That's for 2^31 "a"s in a row.) Note that for python for the same file you will get: ``` OverflowError: Parser column offset overflow - source line is too big ``` and for perl you will get: ``` Identifier too long at test.pl line 1. ``` For files with 2^32 newlines, Ruby just crashes on my machine with the current parser (prism finishes, but its newline counter overflows so it gets all the offsets wrong). Would it be okay to say: * maximum line: 31 bits * maximum column: 32 bits * maximum file byte size: 32 bits This would also help with memory savings — I would like to only use 32 bits for offsets in the file, as opposed to the current 64 bits I'm using (which seems unnecessarily large). -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118212] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by mame (Yusuke Endoh) 06 Jun '24

06 Jun '24

Issue #6648 has been updated by mame (Yusuke Endoh). I am afraid if it is more difficult than expected to do "launch subprocess Ruby instances with the same settings". I am not very familiar with Windows, but I have heard that there is no concept of "an array of command-line arguments" in Windows. A command line is represented as a single string. On Windows, `system("exe", "ary1", "ary2")` is converted to a single string and executed via the shell (sometimes, I am not sure the condition). This exotic command line argument handling in Windows can lead to [vulnerabilities](https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/). What I'm trying to say is, it could be difficult to guarantee `exec(RbConfig.ruby, *RbConfig.ruby_args, RbConfig.script, *RbConfig.script_args)` will always achieve "launch subprocess Ruby instances with the same settings". If you really want to "launch subprocess Ruby instances with the same settings", we might want to consider a more dedicated API for it, instead of parsing the command line to a string array and passing it to `Kernel#exec`. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108700 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117535] [Ruby master Misc#20432] Proposal for workflow changes related to teeny releases
by ufuk (Ufuk Kayserilioglu) 06 Jun '24

06 Jun '24

Issue #20432 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Misc #20432: Proposal for workflow changes related to teeny releases https://bugs.ruby-lang.org/issues/20432 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open ---------------------------------------- ## Aim - The cadence of CRuby stable releases is very important for how the project is perceived. Users of CRuby want to get more frequent releases with bug and security fixes, so that they feel confident that their projects and businesses continue running smoothly and safely. - More frequent releases make the community see that the CRuby project is active and thriving. It also allows people to keep upgrading to the latest versions of Ruby with newer features and better security. - The current cadence of teeny releases are causing concerns in the community, and there have been multiple examples of late releases in [3.0 series](https://www.reddit.com/r/ruby/comments/r14z39/ruby_303_released/), [3.1 and 3.2 series](https://www.reddit.com/r/ruby/comments/18n54es/why_have_they_not_up… and now [3.3 series](https://bugs.ruby-lang.org/issues/20085). This is creating confusion and doubt in our community and making the community to [ask for a change in bug fix release process](https://bugs.ruby-lang.org/issues/20422). - We all agree that release management is difficult and branch maintainers have a hard job. If we can be making their jobs a little bit easier, they will have more time and opportunities to make more frequent releases. - This proposal aims to improve some of the workflows around stable branch release management so that branch maintainers have the opportunity to make more frequent bug fix and security releases, thus, addressing some of the concerns from the community. ## Proposal(s) 1. A lot of the time of a release manager seems to be spent doing backports to the corresponding stable branch. The current workflow asks bug reports to populate the fields for which stable versions need the fix backported to, and release managers are responsible for keeping up with this list and creating backport commits on stable branches. This process is fragile, since the release managers are usually the people with the least amount of context on the particulars of a bug-fix and have to apply the same changes to a different branch and resolve any potential conflicts. This is a task best done by people who already have the most amount of context on the change: the original bugfix author. As a result, my suggestion is to make it mandatory for any change that needs to be backported to have backport PRs opened (or corresponding backport patches attached to the Redmine tickets) by the author for the relevant stable branches. That way the authors of changes will be responsible for making sure that the tests pass and the changes apply cleanly on older branches, allowing branch maintainers to come in and merge the PRs, freeing up their time and focus. Since backport PRs will be opened by authors of changes, but only merged by branch maintainers, this will still allow maintainers to control what goes into stable branches. 2. It also seems like branch maintainers are trying to synchronize releases across different Ruby versions, which is causing delays in getting teeny releases out of the door. In my opinion, each stable branch should be responsible for its own teeny releases and there should be no need to synchronize the cadence between different Ruby versions. This will mean less time waiting for other branch maintainers who might be busy with other life priorities, unblocking branch maintainers to be able to do teeny releases whenever it is convenient. 3. Finally, it is my observation that branch maintainers usually make teeny releases whenever there is a security incident that needs to be addressed. A security fix is most definitely a good reason to make a teeny release, but a teeny release should not wait for a security concern to be addressed. There are many other important bug fixes constantly being backported (or needing backports) such as fixes for crashes, fixes for memory retention/leaks or fixes for other behaviour regressions. It is important for end-users to have those addressed as timely as possible, so I would suggest that branch maintainers aim to make about 6-7 teeny releases every year (some of which will be security releases) in order to deliver value to end-users continuously. ## Conclusions Continuous integration and continuous delivery are one of the greatest changes that have happened in the software engineering sector in the recent decades. They allow us to shorten the time of delivery of new features to end-users and reduce the amount of work-in-progress that is waiting for come into the work, thus reducing waste. By adopting some of the workflow changes that I have suggested above, and maybe other changes that I might have missed, the CRuby core team has an opportunity to make a positive impact on all the users of the Ruby language and to increase the quality perception of the project as a result. For that reason, I hope my proposals are considered and implemented by the Core team. Thanks for your consideration. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:117470] [Ruby master Bug#20416] IO#read doesn't preserve buffer encoding if `maxlen = nil`
by andrykonchin (Andrew Konchin) 06 Jun '24

06 Jun '24

Issue #20416 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20416: IO#read doesn't preserve buffer encoding if `maxlen = nil` https://bugs.ruby-lang.org/issues/20416 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `IO#read(nil, buffer)` doesn't change buffer's encoding, but it does when `maxlen` parameter is specified: ```ruby buffer = "".encode(Encoding::ISO_8859_1) File.open("test.rb").read(1000, buffer).encoding # => #<Encoding:ISO-8859-1> File.open("test.rb").read(nil, buffer).encoding # => #<Encoding:UTF-8> ``` I would expect changing buffer encoding in all the cases. -- https://bugs.ruby-lang.org/

4 5