Project

General

Profile

Actions

Bug #18658

open

Need openssl 3 support for Ubuntu 22.04 (Ruby 2.7.x and 3.0.x)

Added by schneems (Richard Schneeman) 8 months ago. Updated 5 months ago.

Status:
Open
Priority:
Normal
Target version:
-
[ruby-core:108056]

Description

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:

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?


Related issues 1 (0 open1 closed)

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

Updated by mame (Yusuke Endoh) 8 months ago

  • Assignee set to rhenium (Kazuki Yamaguchi)

Updated by Eregon (Benoit Daloze) 8 months ago

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).

Updated by mame (Yusuke Endoh) 8 months ago

@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.

Updated by hsbt (Hiroshi SHIBATA) 8 months ago

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

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

Updated by schneems (Richard Schneeman) 8 months ago

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.

Updated by mame (Yusuke Endoh) 8 months ago

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.

Updated by rhenium (Kazuki Yamaguchi) 8 months ago

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.

Updated by Eregon (Benoit Daloze) 7 months ago

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.

Updated by larskanis (Lars Kanis) 6 months ago

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.

Updated by Eregon (Benoit Daloze) 6 months ago

@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.)

Actions #12

Updated by hsbt (Hiroshi SHIBATA) 6 months ago

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

Updated by jhealy (James Healy) 5 months ago

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

Updated by Eregon (Benoit Daloze) 5 months ago

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.

Updated by Eregon (Benoit Daloze) 5 months ago

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).

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0