ubuntu linux support for openssl 3.x

[mason124124]

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/huwen/dev/tools/gradle_user_home/native/libnetty_tcnative_linux_x86_64.so: libssl.so.1.0.0: cannot open shared object file: No such file or directory
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:287)

looks like the libnetty_tcnative_linux_x86_64.so requires openssl 1.0.0. Is this PR fix the issue?
c9b4b6a

When will 2.0.66.FINAL be released?

[gapropp123]

Hi @mason124124, version 2.0.66.Final has been released. Are you still experiencing that issue? I'm currently on this version and still facing it

[vinsonxing]

Same issue here....

[alexanderankin]

When i download the latest release and do the following check, i get:

$ wget https://repo1.maven.org/maven2/io/netty/netty-tcnative/2.0.72.Final/netty-tcnative-2.0.72.Final-linux-x86_64.jar
$ unzip -jo netty-tcnative-2.0.72.Final-linux-x86_64.jar  META-INF/native/libnetty_tcnative_linux_x86_64.so
$ ldd libnetty_tcnative_linux_x86_64.so | grep libssl
	libssl.so.1.0.0 => not found

however, when i compile it from source with ./mvnw package (after having apt installed:

netty-tcnative/.github/workflows/codeql-analysis.yml

Lines 79 to 80 in 53102a1

	- name: Install tools / libraries
	run: sudo apt-get update && sudo apt-get -y install autoconf automake libtool libtool-bin make tar libapr1-dev libssl-dev cmake perl ninja-build

i can find these files:

$ find . -name '*.so'
./openssl-static/target/openssl/lib/ossl-modules/legacy.so
./openssl-static/target/openssl-source/providers/legacy.so
./openssl-static/target/openssl-source/test/p_test.so
./openssl-static/target/openssl-source/test/p_minimal.so
./openssl-dynamic/target/native-jar-work/META-INF/native/libnetty_tcnative_linux_x86_64.so
./openssl-dynamic/target/native-build/target/lib/libnetty_tcnative.so
./openssl-dynamic/target/native-build/target/lib/libnetty_tcnative-@VERSION@.so
./openssl-dynamic/target/native-build/.libs/libnetty_tcnative.so
./openssl-dynamic/target/native-build/.libs/libnetty_tcnative-@VERSION@.so
./openssl-dynamic/target/test-classes/META-INF/native/linux64/libnetty_tcnative.so
./openssl-dynamic/target/native-lib-only/META-INF/native/linux64/libnetty_tcnative.so
$ for i in $(find . -name '*.so'); do echo $i $(ldd $i | grep ssl); done
./openssl-static/target/openssl/lib/ossl-modules/legacy.so
./openssl-static/target/openssl-source/providers/legacy.so
./openssl-static/target/openssl-source/test/p_test.so
./openssl-static/target/openssl-source/test/p_minimal.so
./openssl-dynamic/target/native-jar-work/META-INF/native/libnetty_tcnative_linux_x86_64.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x0000717842351000)
./openssl-dynamic/target/native-build/target/lib/libnetty_tcnative.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007ee16d3d9000)
./openssl-dynamic/target/native-build/target/lib/libnetty_tcnative-@VERSION@.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007416c09a6000)
./openssl-dynamic/target/native-build/.libs/libnetty_tcnative.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007dc672f90000)
./openssl-dynamic/target/native-build/.libs/libnetty_tcnative-@VERSION@.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007cff67a6b000)
./openssl-dynamic/target/test-classes/META-INF/native/linux64/libnetty_tcnative.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x0000750477550000)
./openssl-dynamic/target/native-lib-only/META-INF/native/linux64/libnetty_tcnative.so libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x000075d2daea3000)

so what's going on?

[chrisvest]

We build netty-tcnative for OpenSSL 1.x. And OpenSSL 3.x is not ABI compatible, so we can't use it. When you build tcnative yourself with OpenSSL 3.x installed, your local version will link to OpenSSL 3.x, so that works.

I recommend you just use our static linked boringssl variant instead. It's faster, has more features, and just sidesteps the OpenSSL version situation entirely.

[alexanderankin]

@chrisvest any perspective on fixing the openssl version situation - that is switching to exclusively v3? can you direct me on what can/should be done? relevant ci scripts i can start trying to run locally to test my changes to contribute this? openssl v1 branches on the openssl repo look like they havent been updated in 2 years and openssl 3.5 is going to/should turn into a base requirement very quickly (pqc - harvesting data attacks)

[alexanderankin]

err, looks like boringssl static variant does work for my test case, but im not convinced upgrading openssl versions is not still pertinent in case that variant must be used for whatever case...