Am 24.01.2014 um 13:20 schrieb Phil Hannent <p...@hannent.co.uk>:
> ...
>
> 1, How is Qt 5.2.0 able to make SSL connections when the required
> DLL's are not shipped in the pre-compiled Qt downloads?
In one word: "plugins" - or more specifically: dlopen (Unix) respective
LoadLibrary (Windows).
So even "Dependency Walker" might not show that dependency Qt most likely tries
to resolve for any OpenSSL library it finds *at runtime*.
And that is also the dangerous part (-> "DLL Injection") when one does a
library search with /relative/ paths, like
handle = LoadLibrary("DoNotDoThis.dll")
because Windows will then start to search in its usual manner, which usually
involves the "working directory"(or at least /did/ involve in the past, or
unless some "search path" related options are set e.g. with LoadLibraryEx). And
usually the user has write permission to the "current work directory" and can
(be tricked into) put whatever malicious DLL he wishes which is then
dynamically "injected".
To be fair, the same can happen on other platforms, too, to some extend. It's
just that the way Windows does (did?) resolve DLLs made it particularly easy
(e.g. OS X is particularly picky about which shared libs it accepts).
The problem is surprisingly easy to solve: "Don't search with relative paths -
ever!"
* Only search for plugins within known locations (which are considered
reasonably safe, since a non-admin user typically has no write access to those
places)
* Restrict the search path otherwise with the corresponding settings of
LoadLibraryEx (I'm almost sure there are some, like
LOAD_LIBRARY_SEARCH_APPLICATION_DIR, which restricts the search to the, well,
application directory only)
I know, the above is somewhat unrelated to the actual question (and Qt does it
right - right? ;)), but I thought it is worth repeating then and when.
So to respond to the actual question: Qt is able to search for SSL
functionality (which in turn will resolve it's dependencies) *at runtime*, and
if it's there, it's there (and will be used by Qt/QWebkit).
> 2, How can I stop the error message when there is no DLLs for me to bundle?
First off, maybe it is possible (I think it is) to analyse a *running
application* with Dependency Walker, then you should be able to detect plugin
linkage like OpenSLL and see its dependencies and where they come from.
Apparently your application does use SSL by making https:// connections to
Google services. Probably Google enforces https (even when connecting to
http://whatever.google.com), once Google sees that your browser is SSL enabled,
which seems to be the case on certain client machines.
And even if you don't connect to those services, QWebKit will still try to
resolve that OpenSSL library - or is that a deferred initialisation until a
https connection is attempted? Then you would be lucky, because that would mean
you could try to supress those https connections. But I doubt that is the case
(the deferred initialisation), because even before connection time QWebkit
needs to know its capabilities and advertise them during handshake with the
server (I assume). Which would mean you probably have to ship a working OpenSSL
+ dependencies library if you want to make sure that your QWebkit enabled Qt
app runs everywhere (even with incompatible libraries installed e.g. in
c:\Windows\System32 or wherever Qt searches for OpenSSL libraries)
Cheers,
Oliver
>
> Regards
> Phil
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
