App diverting to host OS's openssl libraries in runtime

Creating AppImages
1

I packaged an app that uses OpenSSL and worked around the issue with loading system certificates, but now it seems like I’m bouncing off another OpenSSL-related problem.

It’s a Qt app packaged using linuxdeploy. When running it, on startup it spits out, among others, these three error lines in the log:

qt.network.ssl: QSslSocket: cannot resolve SSL_get1_peer_certificate
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_get_base_id
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_load_verify_dir

I thought to myself “okay, it’s looking for OpenSSL 3 symbols in OpenSSL 1.x .so files, but why?” and I ran it through strace:

$strace -e trace=open,openat,close,read,write,connect,accept ./WhatPulse-aaf9decf-x86_64.AppImage 2>&1 | grep crypto
openat(AT_FDCWD, "/tmp/.mount_WhatPub3M3wQ/usr/bin/../lib/libcrypto.so.3", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/tmp/.mount_WhatPub3M3wQ/usr/bin/../lib/libk5crypto.so.3", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/tmp/.mount_WhatPub3M3wQ/usr/bin/../lib/libcrypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/libcrypto.so", O_RDONLY|O_CLOEXEC) = 29
openat(AT_FDCWD, "/lib64/libcrypto.so.3.0.2", O_RDONLY|O_CLOEXEC) = 29
openat(AT_FDCWD, "/lib64/libcrypto.so.3", O_RDONLY|O_CLOEXEC) = 29
openat(AT_FDCWD, "/lib64/libcrypto.so.1.1.1n", O_RDONLY|O_CLOEXEC) = 29
openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = 29
openat(AT_FDCWD, "/etc/crypto-policies/back-ends/opensslcnf.config", O_RDONLY) = 30
openat(AT_FDCWD, "/etc/crypto-policies/back-ends/openssl.config", O_RDONLY) = 29
openat(AT_FDCWD, "/etc/crypto-policies/back-ends/openssl.config", O_RDONLY) = 29

“No such file or directory” was easily resolved by adding a symlink libcrypto.so → libcrypto.so.3 in the AppDir, but still this weird phenomenon of using files located in /lib64 keeps occurring.

The patched executable in the AppImage seems to testify in a coherent way when questioned using the tried and tested ldd polygraph:

$ ldd ./whatpulse | grep crypto
	libcrypto.so.3 => /tmp/.mount_WhatPuvDSian/usr/bin/./../lib/libcrypto.so.3 (0x00007f7a0c316000)
	libk5crypto.so.3 => /tmp/.mount_WhatPuvDSian/usr/bin/./../lib/libk5crypto.so.3 (0x00007f7a09988000)

So… Why does the app change its mind mid-run and resorts to looking for libcrypto files in /lib64? Any ideas?

2

Please report linuxdeploy related issues to Issues · linuxdeploy/linuxdeploy · GitHub.
linuxdeploy is not part of the AppImage project and its author doesn’t read here.
Thanks!

image

3

Oh, OK! Thank you. I didn’t realize it’s an issue on linuxdeploy’s part, I thought it’s rather me doing something wrong :slight_smile: I’ll open an issue as you suggested, thank you again!