#7947 ipaclient.crsgen_ffi loads compat libcrypto.so instead of current libcrypto.so
Opened 3 months ago by cheimes. Modified 3 months ago

The csrgen_ffi interface prefers to load the compat libcrypto.so for OpenSSL 1.0.2 instead of the recent OpenSSL 1.1.1 libcrypto.so. Since all our development machines and test machines have the old OpenSSL compat installed, we never saw bug https://pagure.io/freeipa/issue/7937

$ podman run -ti fedora:29 /bin/bash
# python3 -c 'import ctypes.util; print(ctypes.util.find_library("crypto"))'
libcrypto.so.1.1
# ldconfig -p | grep libcrypto.so
        libcrypto.so.1.1 (libc6,x86-64) => /lib64/libcrypto.so.1.1
# dnf install -y compat-openssl10
...
Installed:
  compat-openssl10-1:1.0.2o-3.fc29.x86_64 ...
# python3 -c 'import ctypes.util; print(ctypes.util.find_library("crypto"))'
libcrypto.so.10
# ldconfig -p | grep libcrypto.so
        libcrypto.so.10 (libc6,x86-64) => /lib64/libcrypto.so.10
        libcrypto.so.1.1 (libc6,x86-64) => /lib64/libcrypto.so.1.1

It's going to be tricky to fix this issue. We may have to check for multiple OpenSSL libraries to find the best one. OpenSSL 1.1.* has libcrypto.so.1.1, OpenSSL 3.0 is going to have libcrypto.so.3.


And LibreSSL comes with:

python3 -c 'import ctypes.util; print(ctypes.util.find_library("crypto"))'
libcrypto.so.45

ldconfig -p | grep libcrypto.so
        libcrypto.so.45 (libc6,x86-64) => /usr/lib64/libcrypto.so.45
        libcrypto.so.1.1 (libc6,x86-64) => /lib64/libcrypto.so.1.1
        libcrypto.so (libc6,x86-64) => /usr/lib64/libcrypto.so

Is it necessary to choose a specific one? Is it an issue?
With related PRs all these libs can be feed to csrgen_ffi via a general 'crypto' lib.

It's mostly an issue for testing. We don't test with the correct library that will be used by most users. It's also not elegant to load yet another libcrypto.so into a process.

Login to comment on this ticket.

Metadata