Force system QT libraries to use openssl libraries shipped with the application
-
I asked this here -> https://stackoverflow.com/questions/44814689/force-system-qt-libraries-to-use-openssl-libraries-shipped-with-the-application
My application = libssl.so (1.0.2f) + libcrypto.so (1.0.2f) + my_app_exe
On Debian 9, QT version is 5.7 and openssl is 1.0.2l
my_app_exe returns 1.0.2l for QSslSocket::sslLibraryVersionString(), which means its using system openssl version.
Can I force QT libraries to somehow use openssl shipped along with my application?
I've tried setting library path using QCoreApplication::addLibraryPath(const QString &path), but QT library still picks up system openssl version.
Constraints:
Can't recompile QT library thats present on the system
Can't ship QT library along with the application
Can't change RPATH on system QT libraries
my_app_exe already uses RPATH which points to the current directory where shipped openssl resides. -
Hi, and welcome to the Qt Dev Net!
@NulledPointer said in Force system QT libraries to use openssl libraries shipped with the application:
Can I force QT libraries to somehow use openssl shipped along with my application?
May I ask why you want to do that?
OpenSSL is a security library. Old versions can contain known, exploitable security holes, so it sounds like a good idea to use the latest version whenever it's available. This way, when the end user upgrades OpenSSL on their system, your Qt application will automatically pick up the new OpenSSL.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@JKSH One would do this to ensure that the libraries used are the proper libraries which are expected in the program. In much the same way as we deploy the appropriate versions of Qt libraries, why not use a KNOWN library when deploying the libssl and libcrypto libraries?
This has become the bane of my existence, and I am here in search of WHY it will work when it is in QtCreator and NOT work when deployed with the EXACT same loaded library files.
By way of venting, this old question gets some new life. I have seen many "answers" which usually consist of "The user should install....", which anyone who has ever actually deployed retail software knows is an absolute NIGHTMARE.
Witness ProtonVPN! This commercial application is deployed with a specific (v1.1.1j) set of OpenSSL libraries. Why? Because it is developed with that version and is tested with that version. Why opt to allow the end user to change the libraries and break your application at will? That's just self-defeating.
To any who subjected themselves to this answer, "Thank you for comiserating."
-
@ThirdStrand said in Force system QT libraries to use openssl libraries shipped with the application:
I am here in search of WHY it will work when it is in QtCreator and NOT work when deployed with the EXACT same loaded library files.
Can you clarify what you mean by "not work"?
- If you mean "It doesn't load OpenSSL", then check that you have deployed all libraries correctly (including the OpenSSL ones). See https://wiki.qt.io/Deploy_an_Application_on_Windows -- it is written for Windows but the principles apply to Linux too.
- If you mean "It loads OpenSSL from a different location", then you'll need to look at how the OS sets library loading priorities.
Either way, if you would like further assistance, please provide more details of how it fails to work, how you've deployed it, and your OS and Qt versions.
-
@ThirdStrand said in Force system QT libraries to use openssl libraries shipped with the application:
@JKSH One would do this to ensure that the libraries used are the proper libraries which are expected in the program. In much the same way as we deploy the appropriate versions of Qt libraries, why not use a KNOWN library when deploying the libssl and libcrypto libraries?
If you want to use known libraries in your app without the possibility of user interference you should probably use static libraries and not dynamic. Because even if the other libraries are not in the system path there is always at least one user who might want to exchange your library with another one - perhaps optimized for his computer ;) Had this a couple of times on windows with DLLs and a lot with java apps where users just replaced „outdated“ libraries.
This has become the bane of my existence, and I am here in search of WHY it will work when it is in QtCreator and NOT work when deployed with the EXACT same loaded library files.
I didn‘t see your used OS but I could imagine that Qt Creator uses LD_PRELOAD mechanism to ensure that the specific libs are loaded first. This at least should work an Linux, I don‘t know any trick for that on windows. AFAIK macOS offers a similar mechanism to Linux.
By way of venting, this old question gets some new life. I have seen many "answers" which usually consist of "The user should install....", which anyone who has ever actually deployed retail software knows is an absolute NIGHTMARE.
Witness ProtonVPN! This commercial application is deployed with a specific (v1.1.1j) set of OpenSSL libraries. Why? Because it is developed with that version and is tested with that version. Why opt to allow the end user to change the libraries and break your application at will? That's just self-defeating.
Still this doesn‘t prevent the user from changing the libs themselves. And given the fact that the build environment doesn‘t often change it might very well be that they will be shipping an „outdated“ version - because the app was developed with it - and tested. When I worked on Air Traffic Control Software we almost never updated our libraries - because they were „tested“.
As I said earlier: If you want to prevent user modification use static linking. This way the size of your deployed app will also shrink.
But be sure to check possible licensing restrictions.
