The Qt version we use within the AppImage (5.15) does attempt to dl_open an OpenSSL library of the 1.1.1 family (AFAIR they are API/ABI compatible). If loading this shared object fails, downloading drumkits will not be possible.
However, some older OS versions, like Ubuntu 16.04, still have a 1.0.1 while other might even omit it all together and just ship >=v3. (e.g. Fedora 38 I used for testing). The latter might occur more often in the future since 1.1.1 reaches LTS end on 11.09.2023.
To mitigate this problem, we add our own libcrypto.so.1.1 and libssl.so.1.1 in the AppImage. They are build from source using the latest 1.1.1 series tag (1_1_1t). I also added an info log message during startup (just for the AppImage build) that indicate which OpenSSL version is used.
Bundling crypto libraries is bad. I know. But I think it is better than use HTTP instead of HTTPS requests (as shipping AppImages unable to download kits is out of the question).
@cme what do you think? Is this something we should do?
The Qt version we use within the AppImage (5.15) does attempt to
dl_openan OpenSSL library of the 1.1.1 family (AFAIR they are API/ABI compatible). If loading this shared object fails, downloading drumkits will not be possible.However, some older OS versions, like Ubuntu 16.04, still have a 1.0.1 while other might even omit it all together and just ship >=v3. (e.g. Fedora 38 I used for testing). The latter might occur more often in the future since 1.1.1 reaches LTS end on 11.09.2023.
To mitigate this problem, we add our own
libcrypto.so.1.1andlibssl.so.1.1in the AppImage. They are build from source using the latest 1.1.1 series tag (1_1_1t). I also added an info log message during startup (just for the AppImage build) that indicate which OpenSSL version is used.Bundling crypto libraries is bad. I know. But I think it is better than use HTTP instead of HTTPS requests (as shipping AppImages unable to download kits is out of the question).
@cme what do you think? Is this something we should do?
addresses #1836