Should we re-install ruby when this project updates the OpenSSL version for it?

[mohamedhafez]

So taking a look at aa71a6c, it looks like the version of OpenSSL used and baked to a particular ruby version can be changed.

For this particular change it probably doesn't matter to re-install, but let's say the OpenSSL version was incremented to address a security issue? Should we re-install our versions of ruby if that happens? Or is it dynamically linked to whatever the latest OpenSSL 3.0.x homebrew has installed on my machine for example, or whatever version our Linux package manager has updated it to? Or is there an option to do so if not, so I don't have to continually watch for new OpenSSL releases?

[mohamedhafez]

So according to #2319 (comment), it looks like ruby-build will use a compatible homebrew or system openssl if they are available and fit the range of acceptable versions.

My question still is though, if Homebrew or apt updates their version of openssl, do our already-installed rubies automatically get to use that new version?

[mislav]

If Homebrew or apt update their version of OpenSSL, already-installed rubies do automatically benefit from that new version.

ruby-build detects Homebrew and links the compiled Ruby version to the output of brew --prefix openssl.

$ ls -l `brew --prefix openssl`
lrwxr-xr-x  1 mislav  admin  25 Jul  5 17:01 /opt/homebrew/opt/openssl@3 -> ../Cellar/openssl@3/3.3.1

With Homebrew's version management, that location is a symlink that is updated to the latest patch version Homebrew has installed for that release branch. In my case, openssl@3 resolves to OpenSSL 3.3.1, but that will get updated whenever I run brew upgrade openssl@3.

If, on the other hand, apt or a similar package manager was used to install OpenSSL "globally" on the system, Ruby will also benefit from it being upgraded since the newer package will override the old one.

Finally, to address your original question: if no Homebrew or system-level OpenSSL was found, ruby-build will automatically download and compile a version of OpenSSL scoped to the Ruby version being installed. Unless someone manually reinstalls a newer OpenSSL version under that same Ruby version, OpenSSL will never get upgraded. This is, as you might have already insinuated, a security risk to some, but I see it as a tradeoff for user-friendliness when installing Ruby versions. Typically, apps running in developer environments that use ruby-build aren't exposed to the public internet, and if someone is hosting a Ruby application in production, they will most likely link to a system OpenSSL that is kept up to date.

[mohamedhafez]

Awesome! I wonder for stability's sake, would it be possible to pass an option to link to an LTS openssl release like [email protected] instead of openssl@3, assuming both are installed on my machine? (a different package had openssl@3 as a requirement so I can't just remove it unfortunately)

Or is it basically not an issue, and its pretty unlikely that a new openssl 3.x will be incompatible with already-installed rubies?

[mislav]

With Homebrew it's possible to install OpenSSL 3.0.x specifically and then instruct ruby to link to it:

brew install [email protected]
ruby-build 3.2.2 /opt/rubies/ruby-3.2.2 -- --with-openssl-dir="$(brew --prefix [email protected])"

This ruby should never get upgraded to a newer OpenSSL 3.x version.

and its pretty unlikely that a new openssl 3.x will be incompatible with already-installed rubies?

Unlikely but could happen. If you're concerned about that, then lock a compiled Ruby version to an OpenSSL 3.0.x installation.