Repository navigation
Openssl 3.0 support #1150
Description
Activity
@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 just changed the function that returns the openssl version to return 1.1 instead.
@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 )
@charlespierce I think it would be fairly simple to swap out
atohttpcforreqwest::blocking, I'll give it a try over the coming few days if you're interested?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.
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
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
Reacted by 김홍수 and DannyVolta 1.0.7 was just published, which includes support for OpenSSL 3.0, so this should be resolved!
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 directoryThis is my
opensslversion:$ 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/opensslI suspect that this is an artifact of
openssl@1.1being installed by Homebrew on my system. I never installed this directly. However, theopenssl@1.1package appears to be a dependency of a variety of other packages, most notably my systemnode,python@3.9, andtmux:$ 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 └── ncursesThese 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!
@jeremyckahn This is the second time a similar issue has came up. The last time this came up was when openssl 3.0 was not supported and volta cannot detect that libssl 1.1 is also installed. There needs to be a way to override the detected openssl version.
This is fixed as of version 1.0.8.
I tested on Dora Linux 36.
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.