Bug #18658: Need openssl 3 support for Ubuntu 22.04 (Ruby 2.7.x and 3.0.x)

• Status: Open
• Priority: Normal
• Assignee: rhenium (Kazuki Yamaguchi)
• Target version: -
• ruby -v: 3.0
• Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN

[schneems (Richard Schneeman)]

Ubuntu 22.04 is being released soon and ships with openssl 3. As of now Ruby 2.7.x and 3.0.x are under core support and will not build on Ubuntu 22.04 with openssl (Ruby 3.1.x can compile).

When attempting to compile 3.0.3 on Ubuntu 22 it issues this warning:

*** Following extensions are not compiled:
openssl:
  Could not be configured. It will not be installed.
  /ruby-3.0.3/ext/openssl/extconf.rb:113: OpenSSL >= 1.0.1, < 3.0.0 or LibreSSL >= 2.5.0 is required
  Check ext/openssl/mkmf.log for more details.

Here are some existing issues/PRs that I could find:

• https://github.com/ruby/openssl/issues/369
• https://github.com/ruby/openssl/pull/399

Ideally I would like to compile and support all non-EOL Ruby versions for Ubuntu 22 on release day. Are there any plans to backport support for OpenSSL 3 to Ruby 3.0 and 2.7?

[mame (Yusuke Endoh)]

• Assignee set to rhenium (Kazuki Yamaguchi)

[Eregon (Benoit Daloze)]

This would be particularly useful given it's often impossible to get an older openssl version on a system
(and if one compiles their own, then system packages like databases won't link against the manually-compiled libssl and so typically segfault due to 2 libssl loaded in the same process).

[vo.x (Vit Ondruch)]

https://src.fedoraproject.org/rpms/ruby/c/2da7a540e7714777b93c430b4f252838b555b703
https://gitlab.com/redhat/centos-stream/rpms/ruby/-/commit/9b1bf408282ab378b5d8b06ce7d7debd2a5dd1d7

These ^^ are the patches applied in Fedora and c9s if it helps. Unfortunately, OpenSSL 3.x breaks some stuff such as net-ssh gem:

https://github.com/net-ssh/net-ssh/issues/843

[mame (Yusuke Endoh)]

@schneems (Richard Schneeman) How about manually downloading and installing openssl-3.0.0.gem?

wget https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.3.tar.gz
tar xf ruby-3.0.3.tar.gz
cd ruby-3.0.3
./configure --prefix=/path/to ...
make
make install
wget https://rubygems.org/downloads/openssl-3.0.0.gem
/path/to/bin/gem install openssl-3.0.0.gem

After that, I can use gem install rails or anything as usual.

This would be a FAQ after Ubuntu 22.04 is released. I'd like to guide this workaround as a short-term measure if it works well.

I'm never against the backport, but I don't know if it will happen since the patch would be huge. Personally I want @rhenium (Kazuki Yamaguchi) to spend his time to support OpenSSL 3 officially (with no deprecation warnings) in Ruby 3.2, rather than to create a backport patch for older Rubies.

[hsbt (Hiroshi SHIBATA)]

FYI: https://bugs.launchpad.net/ubuntu/+source/ruby2.7/+bug/1946190

Ubuntu backported openssl-3.0.0 for their ruby3.0 package.

[schneems (Richard Schneeman)]

After that, I can use gem install rails or anything as usual.

Thank you for the idea Mame. I think that would maybe not work with people using bundle exec to load their program as that gem is not on the load path, but I could consider compiling without openssl and then detecting and requiring customers to add that gem to their Gemfile via logic in the buildpack. I'm assuming that if someone adds that gem to their buildpack all other gems depending on openssl would "just work" even if Ruby is not compiled with openssl support? It sounds like that is the case.

I am curious about the difference between https://github.com/ruby/ruby/tree/master/ext/openssl and https://github.com/ruby/openssl. I do not fully understand the cost or difficulty of maintaining openssl support in Ruby. On the surface it seems that they are the same. I am curious if there is a deeper issue preventing using the newer version in Ruby 2.7 and 3.0?

Ubuntu backported openssl-3.0.0 for their ruby3.0 package.

We've compiled with patches before, but generally want to run "stock" ruby as much as possible to minimize surprises for developers as well as to decrease support surface area. Right now if there's a bug in compilation it's my problem, or with the setup via the build pack it is my problem if there's a bug in Ruby it's reported upstream. When I start to diverge from upstream Ruby it introduces possibility of a case where my patch introduced the bug. Its not off the table for me, but I want to make sure that I can provide a sustainable and stable experience for customers.

It's good to know that I could use Ubuntu's patch and mirror their support. That would be less burdeon and confusion. One of my other options is to just not support anything before Ruby 3.1 on Ubuntu 22.04 on Heroku as I want to encourage people to upgrade to more recent Rubies as well.

[mame (Yusuke Endoh)]

schneems (Richard Schneeman) wrote in #note-6:

I think that would maybe not work with people using bundle exec to load their program as that gem is not on the load path

Ah indeed.

On the surface it seems that they are the same.

Is that so? We need to be sure of that first.

[rhenium (Kazuki Yamaguchi)]

hsbt (Hiroshi SHIBATA) wrote in #note-5:

FYI: https://bugs.launchpad.net/ubuntu/+source/ruby2.7/+bug/1946190

Ubuntu backported openssl-3.0.0 for their ruby3.0 package.

openssl gem v3.0 is compatible with Ruby 2.6 and later, so it's technically possible for ruby_2_7/ruby_3_0 to include it as a default gem.

However, doing this will introduce slight incompatible changes. The changes are outlined in openssl gem's changelog ("Compatibility notes" section for 3.0.0 (and also for 2.2.0 if backporting to ruby_2_7)): https://github.com/ruby/openssl/blob/v3.0.0/History.md.

This includes dropping support for OpenSSL 1.0.1, which was used by Ubuntu 14.04 and RHEL 6. They were already nearing EOL when Ruby 2.7.0 was released, and they now are, but I think rubyci.org still had them at that time. I'd like branch maintainers to decide if this is acceptable.

Adding support for OpenSSL 3.0 to ruby_2_7/ruby_3_0 while retaining full compatibility would not be a trivial task. I'm reluctant to do it.

schneems (Richard Schneeman) wrote in #note-6:

I am curious about the difference between https://github.com/ruby/ruby/tree/master/ext/openssl and https://github.com/ruby/openssl. I do not fully understand the cost or difficulty of maintaining openssl support in Ruby. On the surface it seems that they are the same.

They basically are. At the current moment, each branch corresponds:

• ruby_2_7: gem v2.1.3
• ruby_3_0: gem v2.2.1 + 2 test-only changes to make CI green
• ruby_3_1: gem v3.0.0

tool/sync_default_gems.rb script should be able to upgrade the default gem in the local checkout of ruby_2_7/ruby_3_0 to the specified commit/tag at ruby/openssl.

[Eregon (Benoit Daloze)]

FYI, related discussion in ruby-build: https://github.com/rbenv/ruby-build/pull/1974

I think Ruby 3.0 should support OpenSSL 3, even if that means dropping support for OpenSSL 1.0.1.
The OS using OpenSSL 1.0.1 are pretty old, I think it's not reasonable to run old OS + recent Ruby, especially at the cost of not being able to use recent OS + recent Ruby.

Probably the same for 2.7 since it's still supported by ruby-core.

[larskanis (Lars Kanis)]

Having helped several co-workers to install ruby-2.7 and 3.0 on their Ubuntu-22.04, I support backporting the openssl-3.0 gem to these ruby versions, similar to how Ubuntu patched their ruby-3.0 package. While it's preferable to use the latest ruby version in development, it's often necessary to verify or debug issues on older versions.

[Eregon (Benoit Daloze)]

@mame (Yusuke Endoh) I tried your approach and it seems to work (I tried on Fedora 36).
I was thinking the make would fail but CRuby 3.0.3 has an early check for openssl 3 and so it works as described.
CRuby 3.0.2 OTOH does not have that check, so needs ./configure --prefix=... --without-openssl.
It's not convenient and it feels suboptimal to have to replicate this workaround manually and in various Ruby installers though.

FWIW, in the context of ruby-build and how to deal with system openssl version mismatch, I was wondering if this technique also works for older Rubies (e.g. Ruby 2.3's openssl gem which wants libssl 1.0), but probably not given that the openssl gem 3.0.0 release needs Ruby >= 2.6.
So I guess for building really old Ruby versions on latest OS (when there is no choice, e.g. setup-ruby, obviously best to avoid the combination), one needs to build their own openssl.

I think backporting openssl gem 3.0.0 to Ruby 2.7 and Ruby 3.0 (and have releases of these 2 with it) would be very helpful.
That'd mean dropping OpenSSL 1.0.1 support in 2.7/3.0, which seems fine enough, only pretty old OS have that, and they can still use older Ruby releases until those users update their OS and ancestral OpenSSL.
(They could maybe even apply your workaround in the other way, to install an older openssl gem.)

[hsbt (Hiroshi SHIBATA)]

• Has duplicate Bug #18820: on aarch64/Android/Termux/Ubuntu jammy server, ALL versions before Ruby 3.1.x don't compile! added

[jhealy (James Healy)]

For folks who use rbenv/ruby-build to manage ruby, https://gist.github.com/yob/08d53a003181aa0fcce9812b1b533870 describes an adapted version of the workaround by @mame (Yusuke Endoh) that can be used to install ruby 3.0 on systems with openssl 3.0

[Eregon (Benoit Daloze)]

Issue at ruby/openssl to have a release supporting OpenSSL 1.0.1 - 3.0.0: https://github.com/ruby/openssl/issues/517.
If there is such a release it should be a no-brainer for Ruby 2.7 and 3.0 to directly support OpenSSL 3.
The next TruffleRuby release supports Ruby 3 and OpenSSL 3, and we did not have even have to drop any supported platforms since OpenSSL 1.0.1 is only used by ancient OS.

[Eregon (Benoit Daloze)]

https://github.com/rbenv/ruby-build/pull/1974 is merged so one solution now is "Use ruby-build" and it will install the right openssl version whenever the system openssl version does not match.

It is not ideal that the system openssl version is not used for 2.7/3.0, but that can only be properly solved by CRuby (this issue).