Openssl 3.0 support

[xsrvmy]

Openssl 3.0 is probably coming out on archlinux and fedora in the next few months, so building against openssl 3.0 is a good idea when there is a chance to do so.

Additionally, fedora 36 and archlinux will probably make openssl executable the 3.0 version, meaning that the current detection mechanism will detect openssl 3.0, even if openssl 1.1 library files are also installed. This already happens on Fedora rawhide, and I had to manually change the sh script to force 1.1 to make it work. Volta should actually look for the latest supported openssl version using soname rather than the output of openssl version.

[charlespierce]

@xsrvmy Thanks for the heads up! I think this may actually be an impetus to swap over to using rustls, since dealing with the wide variety of OpenSSL versions is already a headache and adding another will just make things factorially worse. I'm hoping to do some tests soon to see if there is any impact on the startup time using a rust-based implementation instead of dynamically-linked OpenSSL.

[lakano]

Hi @xsrvmy !
Could you please tell me how you patch the install script to fit on 1.1 please?
I'm also on Fedora rawhide, with OpenSSL 1.1.0 and 3.0.0
Thanks in advance!

[xsrvmy]

I just changed the function that returns the openssl version to return 1.1 instead.

[jensmeindertsma]

@xsrvmy Thanks for the heads up! I think this may actually be an impetus to swap over to using rustls, since dealing with the wide variety of OpenSSL versions is already a headache and adding another will just make things factorially worse. I'm hoping to do some tests soon to see if there is any impact on the startup time using a rust-based implementation instead of dynamically-linked OpenSSL.

I'd be super happy to help migrate the project over to rustls, as that would make things much simpler when it comes to building OpenSSL ( we don't have to do it anymore )

[jensmeindertsma]

@charlespierce I think it would be fairly simple to swap out atohttpc for reqwest::blocking, I'll give it a try over the coming few days if you're interested?

[evenreven]

Confirming what you probably already know, that not only Ubuntu, but also Fedora 36 has switched to OpenSSL 3 and that Volta no longer works.

[xsrvmy]

Can version detection be fixed at least? OpenSSL 1.1 and 3 library files can be installed at the same time. You need to reinstall openssl 1.1.
IIRC, what's actually happening is that the openssl executable is now pointing to version 3, and volta uses the output of the openssl executable to determine the openssl version.

Also, #962

[pwespi]

Ubuntu 22.04 LTS has been released today and running volta in Ubuntu 22.04 results in the following error:
volta: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

See also #1180

[charlespierce]

Volta 1.0.7 was just published, which includes support for OpenSSL 3.0, so this should be resolved!

[jeremyckahn]

I mistakenly reported this issue first at #161 (comment), but I am unable to install Volta on Ubuntu 22.04 due to OpenSSL.

This is what I see when I attempt to install:

$ curl https://get.volta.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 12319  100 12319    0     0  52975      0 --:--:-- --:--:-- --:--:-- 53099
  Installing latest version of Volta (1.0.7)
    Checking for existing Volta installation
    Fetching archive for Linux, version 1.0.7
######################################################################## 100.0%
    Creating directory layout
  Extracting Volta binaries and launchers
    Finished installation. Updating user profile settings.
/home/jeremyckahn/.volta/bin/volta: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

This is my openssl version:

$ openssl version
OpenSSL 1.1.1n  15 Mar 2022

@charlespierce wrote there:

It looks like the install script is downloading the version linked against OpenSSL 1.1.x, but then isn't able to find that version when it actually goes to install, which is quite odd.

After exploring this a little more, I noticed this:

$ which openssl 
/home/linuxbrew/.linuxbrew/bin/openssl

I suspect that this is an artifact of openssl@1.1 being installed by Homebrew on my system. I never installed this directly. However, the openssl@1.1 package appears to be a dependency of a variety of other packages, most notably my system node, python@3.9, and tmux:

$ brew deps --tree --installed

...

node
├── brotli
├── c-ares
├── icu4c
├── libnghttp2
├── libuv
├── openssl@1.1
│   └── ca-certificates
├── python
│   ├── gdbm
│   ├── mpdecimal
│   ├── openssl@1.1
│   │   └── ca-certificates
│   ├── readline
│   │   └── ncurses
│   ├── sqlite
│   │   ├── readline
│   │   │   └── ncurses
│   │   └── zlib
│   ├── xz
│   ├── bzip2
│   ├── expat
│   ├── libffi
│   ├── ncurses
│   ├── unzip
│   │   └── bzip2
│   └── zlib
├── zlib
└── gcc
    ├── gmp
    ├── isl
    │   └── gmp
    ├── libmpc
    │   ├── gmp
    │   └── mpfr
    │       └── gmp
    ├── mpfr
    │   └── gmp
    ├── zstd
    ├── zlib
    └── binutils
        └── zlib

...

openssl@1.1
└── ca-certificates

...

python@3.9
├── gdbm
├── mpdecimal
├── openssl@1.1
│   └── ca-certificates
├── readline
│   └── ncurses
├── sqlite
│   ├── readline
│   │   └── ncurses
│   └── zlib
├── xz
├── bzip2
├── expat
├── libffi
├── ncurses
├── unzip
│   └── bzip2
└── zlib

...

tmux
├── libevent
│   └── openssl@1.1
│       └── ca-certificates
└── ncurses

These aren't particularly exotic packages to have installed, so I suspect others may run into this issue as well. Please let me know if I can help you debug this further!