- ruby-core - ml.ruby-lang.org

[ruby-core:111281] [Ruby master Bug#19234] [3.2.0dev] YJIT code GC can lead to crashes
by byroot (Jean Boussier) 14 Dec '22

14 Dec '22

Issue #19234 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19234: [3.2.0dev] YJIT code GC can lead to crashes https://bugs.ruby-lang.org/issues/19234 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Assignee: k0kubun (Takashi Kokubun) * Target version: 3.2 * ruby -v: ruby 3.2.0dev (2022-12-13T16:07:29Z master a66a69865d) +YJIT [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Filing this bug here in case some people may have observed it too and may have more information, and also to keep track of it for the upcoming 3.2.0 release. After changing some settings on our CI to make sure YJIT's `code_gc` would trigger, we discovered that it sometimes cause crashes. The crash can take many different form (e.g. `[BUG] Segmentation fault at 0x00005604a8e78006` or `[BUG] Illegal instruction at 0x0000aaaacc0ce4c0`), and happens on both `x86` and `arm64`. It however happens very consistently on our CI, but only after running for 15 to 20 minutes and we haven't been able to reduce it to a local reproduction script. When it happens however the backtrace isn't really helpful: ``` -- C level backtrace information ------------------------------------------- /usr/local/ruby/bin/real-ruby(rb_print_backtrace+0x11) [0x5604a8a6df7d] vm_dump.c:770 /usr/local/ruby/bin/real-ruby(rb_vm_bugreport) vm_dump.c:1065 /usr/local/ruby/bin/real-ruby(rb_bug_for_fatal_signal+0xee) [0x5604a8ba927e] error.c:813 /usr/local/ruby/bin/real-ruby(sigsegv+0x4d) [0x5604a89c3ded] signal.c:964 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7fb5b4285420] [0x5604acd31079] ```` Like regular GC bugs, it is likely that the code GC need to trigger at a very specific place for the bug to happen. Our attempts at triggering it manually with `RubyVM::YJIT.code_gc` or to set the executable memory very low to trigger it more often didn't allow for a simpler reproduction. Both @k0kubun and @alanwu are investigating it right now. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111278] [Ruby master Feature#19135] Support `UNIXSocket` on Windows
by ioquatix (Samuel Williams) 14 Dec '22

14 Dec '22

Issue #19135 has been updated by ioquatix (Samuel Williams). I would like to share this credit with @larskanis who was instrumental to getting this PR over the finish line. It was a true team effort with hard compatibility challenges. ---------------------------------------- Feature #19135: Support `UNIXSocket` on Windows https://bugs.ruby-lang.org/issues/19135#change-100629 * Author: ioquatix (Samuel Williams) * Status: Closed * Priority: Normal ---------------------------------------- In recent versions of Windows, the required parts are now supported: https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ This enables UNIXSocket, UNIXServer and UNIXSocket.pair on Windows. The anonymous socket is emulated on Windows using a temporary file, but it's good enough and the best we can do. The semantics is not completely identical. Because these constants are now available, more tests are run on Windows. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111263] [Ruby master Bug#19196] The string saved to Tempfile from URI.open escapes "&" characters
by westoque (William Estoque) 13 Dec '22

13 Dec '22

Issue #19196 has been reported by westoque (William Estoque). ---------------------------------------- Bug #19196: The string saved to Tempfile from URI.open escapes "&" characters https://bugs.ruby-lang.org/issues/19196 * Author: westoque (William Estoque) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When I am reading the string response from a URI.open, the response is not equivalent to the response body. URI.open escapes the response body string. How to reproduce: ``` url = "https://www.podcastone.com/podcast?categoryID2=1237" handle = URI.open(url) => #<Tempfile:/path/to/tempfile> puts handle.read .... https://dts.podtrac.com/redirect.mp3/pdst.fm/e/chrt.fm/track/E2G895/aw.noxs…... ``` The string in the browser says "https://dts.podtrac.com/redirect.mp3/pdst.fm/e/chrt.fm/track/E2G895/aw.noxs…" Notice the characters "&#38" My initial research is that it's because the Tempfile that gets created is in ascii-8bit which the amperstand is a "38". We should create a way to force the encoding of the Tempfile to UTF8 so that this character is not escaped. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111183] [Ruby master Misc#19178] How does CRuby handle CVE issues in stdlib gems which get patched?
by Segaja (Andreas Schleifer) 13 Dec '22

13 Dec '22

Issue #19178 has been reported by Segaja (Andreas Schleifer). ---------------------------------------- Misc #19178: How does CRuby handle CVE issues in stdlib gems which get patched? https://bugs.ruby-lang.org/issues/19178 * Author: Segaja (Andreas Schleifer) * Status: Open * Priority: Normal ---------------------------------------- If there is a CVE issue in one of the stdlibs ( https://stdgems.org/ ) which gets patched, what is CRubys approach on how to push this critical fix to the users? As far as I know stdlibs get only updated for the users if CRuby releases a new version. So will CRuby always release a new version if there is a critical fix an stdlib "needs" to be updated? -- https://bugs.ruby-lang.org/

6 13

[ruby-core:111262] [Ruby master Bug#19195] Pattern match pin becomes syntax error if there is newline before closing paren
by tompng (tomoya ishida) 12 Dec '22

12 Dec '22

Issue #19195 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19195: Pattern match pin becomes syntax error if there is newline before closing paren https://bugs.ruby-lang.org/issues/19195 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Syntax OK ~~~ruby 1 in ^( 1) # => true ~~~ Syntax error. I think it should be syntax ok. ~~~ruby 1 in ^( 1 ) # => syntax error, unexpected '\n', expecting ')' ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111259] [Ruby master Bug#19007] Unicode tables differences from Unicode.org 14.0 data
by hsbt (Hiroshi SHIBATA) 12 Dec '22

12 Dec '22

Issue #19007 has been updated by hsbt (Hiroshi SHIBATA). Thanks. I create the [3.3 milestone](https://bugs.ruby-lang.org/versions/71) ---------------------------------------- Bug #19007: Unicode tables differences from Unicode.org 14.0 data https://bugs.ruby-lang.org/issues/19007#change-100569 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) * ruby -v: 3.2.0 6898984f1cd * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED ---------------------------------------- I found the header in Unicode Emoji 14.0 data files had changed slightly (and again at 15.0), but `enc/unicode/case-folding.rb` didn't follow it. Then I fixed it and rebuilt the headers under `enc/unicode/14.0.0`, `name2ctype.h` had diffences from the master, as bellow. `CR_Lower`, `CR_Cased` and `CR_Other_Lowercase` just seem misses in the previous operation, and no problems. But U+11720..U+11721 in `CR_Grapheme_Cluster_Break_SpacingMark` is absent in the original data of the Unicode.org. According to @naruse's investigation, it was removed at the commit [Update to Unicode 14.0.0], while U+11720 is still SpacingMark in the latest https://www.unicode.org/reports/tr29/. [Update to Unicode 14.0.0]: https://github.com/latex3/unicode-data/commit/5570040ac8a30e2c2ca4912d415ec… ```diff diff --git a/enc/unicode/14.0.0/name2ctype.h b/enc/unicode/14.0.0/name2ctype.h index 99a3eeca190..f49e5cd7273 100644 --- a/enc/unicode/14.0.0/name2ctype.h +++ b/enc/unicode/14.0.0/name2ctype.h @@ -1565,7 +1565,7 @@ static const OnigCodePoint CR_Graph[] = { /* 'Lower': [[:Lower:]] */ static const OnigCodePoint CR_Lower[] = { - 664, + 668, 0x0061, 0x007a, 0x00aa, 0x00aa, 0x00b5, 0x00b5, @@ -2196,6 +2196,10 @@ static const OnigCodePoint CR_Lower[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10cc0, 0x10cf2, 0x118c0, 0x118df, 0x16e60, 0x16e7f, @@ -12651,7 +12655,7 @@ static const OnigCodePoint CR_Math[] = { /* 'Cased': Derived Property */ static const OnigCodePoint CR_Cased[] = { - 151, + 155, 0x0041, 0x005a, 0x0061, 0x007a, 0x00aa, 0x00aa, @@ -12763,6 +12767,10 @@ static const OnigCodePoint CR_Cased[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10c80, 0x10cb2, 0x10cc0, 0x10cf2, 0x118a0, 0x118df, @@ -22615,7 +22623,7 @@ static const OnigCodePoint CR_Extender[] = { /* 'Other_Lowercase': Binary Property */ static const OnigCodePoint CR_Other_Lowercase[] = { - 20, + 24, 0x00aa, 0x00aa, 0x00ba, 0x00ba, 0x02b0, 0x02b8, @@ -22636,6 +22644,10 @@ static const OnigCodePoint CR_Other_Lowercase[] = { 0xa770, 0xa770, 0xa7f8, 0xa7f9, 0xab5c, 0xab5f, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, }; /* CR_Other_Lowercase */ /* 'Other_Uppercase': Binary Property */ @@ -37049,7 +37061,7 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_Extend[] = { /* 'Grapheme_Cluster_Break_SpacingMark': Grapheme_Cluster_Break=SpacingMark */ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { - 161, + 160, 0x0903, 0x0903, 0x093b, 0x093b, 0x093e, 0x0940, @@ -37183,7 +37195,6 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { 0x116ac, 0x116ac, 0x116ae, 0x116af, 0x116b6, 0x116b6, - 0x11720, 0x11721, 0x11726, 0x11726, 0x1182c, 0x1182e, 0x11838, 0x11838, ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111258] [Ruby master Bug#19007] Unicode tables differences from Unicode.org 14.0 data
by duerst 12 Dec '22

12 Dec '22

Issue #19007 has been updated by duerst (Martin Dürst). hsbt (Hiroshi SHIBATA) wrote in #note-6: > @duerst Is there any action for Ruby 3.2 related this? If there is nothing to do for Ruby 3.2, I'll remove this from Ruby 3.2 milestone. No, nothing should be needed for Ruby 3.2. I removed it myself. BTW, can we add a "3.3" target version? ---------------------------------------- Bug #19007: Unicode tables differences from Unicode.org 14.0 data https://bugs.ruby-lang.org/issues/19007#change-100566 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) * ruby -v: 3.2.0 6898984f1cd * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED ---------------------------------------- I found the header in Unicode Emoji 14.0 data files had changed slightly (and again at 15.0), but `enc/unicode/case-folding.rb` didn't follow it. Then I fixed it and rebuilt the headers under `enc/unicode/14.0.0`, `name2ctype.h` had diffences from the master, as bellow. `CR_Lower`, `CR_Cased` and `CR_Other_Lowercase` just seem misses in the previous operation, and no problems. But U+11720..U+11721 in `CR_Grapheme_Cluster_Break_SpacingMark` is absent in the original data of the Unicode.org. According to @naruse's investigation, it was removed at the commit [Update to Unicode 14.0.0], while U+11720 is still SpacingMark in the latest https://www.unicode.org/reports/tr29/. [Update to Unicode 14.0.0]: https://github.com/latex3/unicode-data/commit/5570040ac8a30e2c2ca4912d415ec… ```diff diff --git a/enc/unicode/14.0.0/name2ctype.h b/enc/unicode/14.0.0/name2ctype.h index 99a3eeca190..f49e5cd7273 100644 --- a/enc/unicode/14.0.0/name2ctype.h +++ b/enc/unicode/14.0.0/name2ctype.h @@ -1565,7 +1565,7 @@ static const OnigCodePoint CR_Graph[] = { /* 'Lower': [[:Lower:]] */ static const OnigCodePoint CR_Lower[] = { - 664, + 668, 0x0061, 0x007a, 0x00aa, 0x00aa, 0x00b5, 0x00b5, @@ -2196,6 +2196,10 @@ static const OnigCodePoint CR_Lower[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10cc0, 0x10cf2, 0x118c0, 0x118df, 0x16e60, 0x16e7f, @@ -12651,7 +12655,7 @@ static const OnigCodePoint CR_Math[] = { /* 'Cased': Derived Property */ static const OnigCodePoint CR_Cased[] = { - 151, + 155, 0x0041, 0x005a, 0x0061, 0x007a, 0x00aa, 0x00aa, @@ -12763,6 +12767,10 @@ static const OnigCodePoint CR_Cased[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10c80, 0x10cb2, 0x10cc0, 0x10cf2, 0x118a0, 0x118df, @@ -22615,7 +22623,7 @@ static const OnigCodePoint CR_Extender[] = { /* 'Other_Lowercase': Binary Property */ static const OnigCodePoint CR_Other_Lowercase[] = { - 20, + 24, 0x00aa, 0x00aa, 0x00ba, 0x00ba, 0x02b0, 0x02b8, @@ -22636,6 +22644,10 @@ static const OnigCodePoint CR_Other_Lowercase[] = { 0xa770, 0xa770, 0xa7f8, 0xa7f9, 0xab5c, 0xab5f, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, }; /* CR_Other_Lowercase */ /* 'Other_Uppercase': Binary Property */ @@ -37049,7 +37061,7 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_Extend[] = { /* 'Grapheme_Cluster_Break_SpacingMark': Grapheme_Cluster_Break=SpacingMark */ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { - 161, + 160, 0x0903, 0x0903, 0x093b, 0x093b, 0x093e, 0x0940, @@ -37183,7 +37195,6 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { 0x116ac, 0x116ac, 0x116ae, 0x116af, 0x116b6, 0x116b6, - 0x11720, 0x11721, 0x11726, 0x11726, 0x1182c, 0x1182e, 0x11838, 0x11838, ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111257] [Ruby master Bug#19007] Unicode tables differences from Unicode.org 14.0 data
by hsbt (Hiroshi SHIBATA) 12 Dec '22

12 Dec '22

Issue #19007 has been updated by hsbt (Hiroshi SHIBATA). @duerst Is there any action for Ruby 3.2 related this? If there is nothing to do for Ruby 3.2, I'll remove this from Ruby 3.2 milestone. ---------------------------------------- Bug #19007: Unicode tables differences from Unicode.org 14.0 data https://bugs.ruby-lang.org/issues/19007#change-100561 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) * Target version: 3.2 * ruby -v: 3.2.0 6898984f1cd * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED ---------------------------------------- I found the header in Unicode Emoji 14.0 data files had changed slightly (and again at 15.0), but `enc/unicode/case-folding.rb` didn't follow it. Then I fixed it and rebuilt the headers under `enc/unicode/14.0.0`, `name2ctype.h` had diffences from the master, as bellow. `CR_Lower`, `CR_Cased` and `CR_Other_Lowercase` just seem misses in the previous operation, and no problems. But U+11720..U+11721 in `CR_Grapheme_Cluster_Break_SpacingMark` is absent in the original data of the Unicode.org. According to @naruse's investigation, it was removed at the commit [Update to Unicode 14.0.0], while U+11720 is still SpacingMark in the latest https://www.unicode.org/reports/tr29/. [Update to Unicode 14.0.0]: https://github.com/latex3/unicode-data/commit/5570040ac8a30e2c2ca4912d415ec… ```diff diff --git a/enc/unicode/14.0.0/name2ctype.h b/enc/unicode/14.0.0/name2ctype.h index 99a3eeca190..f49e5cd7273 100644 --- a/enc/unicode/14.0.0/name2ctype.h +++ b/enc/unicode/14.0.0/name2ctype.h @@ -1565,7 +1565,7 @@ static const OnigCodePoint CR_Graph[] = { /* 'Lower': [[:Lower:]] */ static const OnigCodePoint CR_Lower[] = { - 664, + 668, 0x0061, 0x007a, 0x00aa, 0x00aa, 0x00b5, 0x00b5, @@ -2196,6 +2196,10 @@ static const OnigCodePoint CR_Lower[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10cc0, 0x10cf2, 0x118c0, 0x118df, 0x16e60, 0x16e7f, @@ -12651,7 +12655,7 @@ static const OnigCodePoint CR_Math[] = { /* 'Cased': Derived Property */ static const OnigCodePoint CR_Cased[] = { - 151, + 155, 0x0041, 0x005a, 0x0061, 0x007a, 0x00aa, 0x00aa, @@ -12763,6 +12767,10 @@ static const OnigCodePoint CR_Cased[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10c80, 0x10cb2, 0x10cc0, 0x10cf2, 0x118a0, 0x118df, @@ -22615,7 +22623,7 @@ static const OnigCodePoint CR_Extender[] = { /* 'Other_Lowercase': Binary Property */ static const OnigCodePoint CR_Other_Lowercase[] = { - 20, + 24, 0x00aa, 0x00aa, 0x00ba, 0x00ba, 0x02b0, 0x02b8, @@ -22636,6 +22644,10 @@ static const OnigCodePoint CR_Other_Lowercase[] = { 0xa770, 0xa770, 0xa7f8, 0xa7f9, 0xab5c, 0xab5f, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, }; /* CR_Other_Lowercase */ /* 'Other_Uppercase': Binary Property */ @@ -37049,7 +37061,7 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_Extend[] = { /* 'Grapheme_Cluster_Break_SpacingMark': Grapheme_Cluster_Break=SpacingMark */ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { - 161, + 160, 0x0903, 0x0903, 0x093b, 0x093b, 0x093e, 0x0940, @@ -37183,7 +37195,6 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { 0x116ac, 0x116ac, 0x116ae, 0x116af, 0x116b6, 0x116b6, - 0x11720, 0x11721, 0x11726, 0x11726, 0x1182c, 0x1182e, 0x11838, 0x11838, ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111256] [Ruby master Bug#19136] OpenSSL::PKey::EC.check_key is useless when linked against OpenSSL 3
by hsbt (Hiroshi SHIBATA) 12 Dec '22

12 Dec '22

Issue #19136 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Third Party's Issue This issue has been filed at https://github.com/ruby/openssl/issues/563 ---------------------------------------- Bug #19136: OpenSSL::PKey::EC.check_key is useless when linked against OpenSSL 3 https://bugs.ruby-lang.org/issues/19136#change-100560 * Author: bannable (Joe Truba) * Status: Third Party's Issue * Priority: Normal * ruby -v: 3.1.2, 2.7.2 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When calling `#check_key` against an `OpenSSL::PKey::EC` instance representing an invalid point for the group, the method always returns true. I believe this is because OpenSSL 3 deprecated `EC_KEY_check_key`, and the underlying call is swapped out for `EVP_PKEY_public_check` in `ruby/openssl` 3+. However, the `EVP_PKEY_public_check` does not serve the same purpose as `EC_KEY_check_key`. `EVP_PKEY_public_check` validates only the resulting public component, and does not validate the private component. **Reproducer** ```ruby # check.rb ver = ARGV[0] gem 'openssl', ver require 'openssl' # ECDSA secp384r1 encoded key where the point is not on the curve pem = <<~INVALID_KEY -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDDA1Tm0m7YhkfeVpFuarAJYVlHp2tQj+1fOBiLa10t9E8TiQO/hVfxB vGaVEQwOheWgBwYFK4EEACKhZANiAASyGqmryZGqdpsq5gEDIfNvgC3AwSJxiBCL XKHBTFRp+tCezLDOK/6V8KK/vVGBJlGFW6/I7ahyXprxS7xs7hPA9iz5YiuqXlu+ lbrIpZOz7b73hyQQCkvbBO/Avg+hPAk= -----END EC PRIVATE KEY----- INVALID_KEY begin result = OpenSSL::PKey::EC.new(pem).check_key rescue => e result = e.message end puts format('%25s: %s','RUBY_VERSION', RUBY_VERSION) puts format('%25s: %s','OPENSSL_LIBRARY_VERSION', OpenSSL::OPENSSL_LIBRARY_VERSION) puts format('%25s: %s','OPENSSL_VERSION', OpenSSL::VERSION) puts format('%25s: %s','result', result) ``` **OpenSSL 1.1.1** ``` $ rvm 2.7 do ruby check.rb 2.1.2 RUBY_VERSION: 2.7.2 OPENSSL_LIBRARY_VERSION: OpenSSL 1.1.1f 31 Mar 2020 OPENSSL_VERSION: 2.1.2 result: EC_KEY_check_key: invalid private key $ rvm 2.7 do ruby check.rb 3.0.1 RUBY_VERSION: 2.7.2 OPENSSL_LIBRARY_VERSION: OpenSSL 1.1.1f 31 Mar 2020 OPENSSL_VERSION: 3.0.1 result: EVP_PKEY_public_check: invalid private key $ rvm 3.1.2 do ruby check.rb RUBY_VERSION: 3.1.2 OPENSSL_LIBRARY_VERSION: OpenSSL 1.1.1f 31 Mar 2020 OPENSSL_VERSION: 3.0.1 result: EVP_PKEY_public_check: invalid private key ``` **OpenSSL 3.0.2** ```ruby $ ruby check.rb RUBY_VERSION: 3.1.2 OPENSSL_LIBRARY_VERSION: OpenSSL 3.0.2 15 Mar 2022 OPENSSL_VERSION: 3.0.1 result: true $ ruby check.rb 3.0.0 RUBY_VERSION: 3.1.2 OPENSSL_LIBRARY_VERSION: OpenSSL 3.0.2 15 Mar 2022 OPENSSL_VERSION: 3.0.0 result: true ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111248] [Ruby master Bug#19192] IO has third data mode, document is incomplete.
by YO4 (Yoshinao Muramatsu) 11 Dec '22

11 Dec '22

Issue #19192 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #19192: IO has third data mode, document is incomplete. https://bugs.ruby-lang.org/issues/19192 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The documentation on the mode parameter of File.open is incomplete, I would like to clarify IO's data mode actual behavior here. document says ``` To specify whether data is to be treated as text or as binary data, either of the following may be suffixed to any of the string read/write modes above: 't': Text data; sets the default external encoding to Encoding::UTF_8; on Windows, enables conversion between EOL and CRLF and enables interpreting 0x1A as an end-of-file marker. 'b': Binary data; sets the default external encoding to Encoding::ASCII_8BIT; on Windows, suppresses conversion between EOL and CRLF and disables interpreting 0x1A as an end-of-file marker. If neither is given, the stream defaults to text data. ``` But actually it's more complicated than that. There is three Data Mode * text mode. Can convert encoding and newline. * binary mode. Cannot convert encoding nor newline. Encoding is treated as Encoding::ASCII_8BIT. * third mode: DOS TEXT mode. That enables conversion between EOL and CRLF and enables interpreting 0x1A as an end-of-file marker. On Windows platform 't' textmode with universal newline conversion. 'b' binary mode. If neither is given, DOS TEXT mode. On other platforms 't' textmode with universal newline conversion. 'b' binary mode. If neither is given, textmode without newline conversion. On Windows, there are some special cases. If Encoding conversion is specified, DOS TEXT mode is ignored and universal newline conversion applied. If access mode is "a+", last (only one) EOF charactor is overwritten when DOS TEXT mode. There are more parameter combinations, see https://gist.github.com/YO4/262e9bd5e44a37a7a2fa9118e271b30b Is this all? I have not fully investigated. Since the topic of data mode spanned access mode and encoding conversion, I don't think my English skills will allow me to summarize this into rdoc without breaking something... -- https://bugs.ruby-lang.org/

2 1