ruby
A openssl gem release supporting OpenSSL 1.0.1 and OpenSSL 3.0.0
Hello, In the context of https://bugs.ruby-lang.org/issues/18658#note-8, I would like to ask what would it take to support OpenSSL 1.0.1-3.0.0 in the Ruby openssl gem? (the current openssl gem release 3.0.0 supports libssl 1.0.2+, not 1.0.1).
Would it be "just" reverting https://github.com/ruby/openssl/pull/396/files or significantly more work? cc @rhenium
This would enable multiple things:
- Being able to build CRuby 2.7 & 3.0 (both still supported) on OS using a system openssl 3, without needing manual workarounds (https://bugs.ruby-lang.org/issues/18658). Having to build your own openssl is inconvenient, and it doesn't work with system packages which link against the system libssl (e.g., database libs) and are used by C extensions.
- The above would also make it trivial to support 2.7 and 3.0 in ruby/setup-ruby in GitHub Actions on Ubuntu 22.04.
- Being able to test TruffleRuby on OracleLinux 6 (that's what used in CI currently, I'm looking to see how we can update that) and being able to use TruffleRuby on recent OS like Ubuntu 22.04 too.
cc @aardvark179
For TruffleRuby, we managed to change the minimum to OracleLinux 7/Ubuntu 16.04, and we now use the openssl gem 3.0.0. That makes it the first Ruby implementation with RUBY_VERSION=3.0.x to support OpenSSL 3.0.0 :D
I think it is still worth to consider supporting OpenSSL 1.0.1 so CRuby 2.7&3.0 could support OpenSSL 3.0.0 too.
Would it be "just" reverting https://github.com/ruby/openssl/pull/396/files or significantly more work? cc @rhenium
I don't remember there was a change that specifically requires OpenSSL 1.0.2+ since then, so probably not much outside it to just make it compile. However, I want to avoid the cost that takes to maintain compatibility in the future when backporting stuff, which comes as a pair with doing so.
I think it was a mistake to keep OpenSSL 1.0.1 compatibility until recently at all. IMHO, realistically, it's fine for Ruby 2.7/3.0 to drop support for 1.0.1.
it doesn't work with system packages which link against the system libssl (e.g., database libs) and are used by C extensions.
To my understanding, this should not be a problem anymore, for example, loading ruby/openssl built against OpenSSL 1.1 and libcurl built against OpenSSL 3.0 in the same process should work fine.
I believe this used to break in Ruby < 2.4 because ext/openssl/openssl_missing.c was exporting conflicting symbols with the other OpenSSL library.
To my understanding, this should not be a problem anymore, for example, loading ruby/openssl built against OpenSSL 1.1 and libcurl built against OpenSSL 3.0 in the same process should work fine.
Interesting. IIRC it was still a problem when mixing OpenSSL 1.0.2 and 1.1. Isn't there a risk when loading those libraries depending on libssl to resolve the symbol to the other version, and that would likely result in a segfault?
To be exact, it should be fine if the platform supports symbol versioning. At least GNU/Linux systems do.
I think using Ruby 2.3's openssl built against OpenSSL 1.0.2 and libcurl built against OpenSSL 1.1 can be a problem. libcurl can run into a function defined in ext/openssl/openssl_missing.c which isn't versioned (so it can be wrongly picked up by dynamic linker) and is naturally incompatible with the rest of OpenSSL 1.1.
The same thing shouldn't happen on Ruby 2.4 as functions in ext/openssl/openssl_missing.c are prefixed with ossl_. I'd be curious if it occurs with Ruby 2.4+ because there must be another issue in that case.
The two issues about that I could find now:
- https://github.com/ruby/setup-ruby/issues/150 it's about Ruby 2.3.8 and mysql
- https://github.com/rbenv/ruby-build/discussions/2014 it's about Ruby 2.1.9 and mysql
So you might be right on Ruby 2.4+ this is no longer an issue. Which means it'd be safe to link Ruby/TruffleRuby to some openssl and yet use system packages using the system libssl.
macOS doesn't have symbol versioning though, right? So if one uses e.g. a custom OpenSSL or LibreSSL from the system, and some gem like mysql2 which then depends on Homebrew's openssl we'd probably run into problems.
Actually, I don't know about macOS. It's strange I don't find similar bug reports on macOS (considering that people casually have multiple OpenSSL installations on a system), so I wonder if something else is preventing it from happening. But it's possible it's just by chance.
Windows shouldn't suffer from this because AFAIK symbols from one OpenSSL are not visible from another OpenSSL at all.
In my understanding, the case of mysql2 gem with macOS and Homebrew are:
- mysql was built with homebrew's openssl.
- When users uses ruby-build without homebrew's openssl, ruby-build try to build openssl by itself.
- mysql2 gem can't find the homebrew's openssl because ruby was built with openssl built by ruby-build.
And they are inconsistent versions like 3.0.x and 1.1.x or others. But this problem was fixed with https://github.com/brianmario/mysql2/pull/1135 at mysql2-0.5.4
Can we close this ticket? The document says that the Ruby/OpenSSL version 3.2.x, 3.1.x and 3.0.x supporting OpenSSL 3.0 (and 3.1). https://github.com/ruby/openssl/blob/master/README.md#compatibility-and-maintenance-policy
