About PySide6 QNetwork hook bundling incompatible dlls from PATH

Hello and thank you for the development of pyinstaller ❤️.

The Issue When packaging a PySide6 application that uses QNetworkAccessManager for https requests, pyinstaller's pyside6 hook bundles libssl-3.dll, libssl-3-x64.dll, libcrypto-3.dll, and libcrypto-3-x64.dll by searching the build machine's PATH. this is a know and already discussed issue. but those dlls should be sourced from a pinned, known-compatible OpenSSL build instead grabbing any available dlls. if those dlls found on PATH are ABI incompatible with the qopensslbackend.dll TLS plugin shipped by pyside6, the frozen application crashes natively with no exception, no traceback or no log output the moment an https request is made. even with sys.exepthook and try/except in place. because the failiure happens inside Qt's c++ layer.

This is not ideal because:

• It is environment dependent. it can pass in local manual testing and fail only when build on CI (github actions). because the CI runner's ships different openssl 3.x build than the developer's machine.
• It is very hard to diagnose. there is no indication that the bundled DLLs are the problem unless the developer happens to compare working and non working builds or manually swaps dlls to bisect. *Off-topic: i just used QNetwork for simple GET. which confused me a lot *

According to qt's docs (https://doc.qt.io/qt-6/ssl.html), openssl backend is designed to dynamically load whatever bundling openssl for licensing reasons.

This closely mirrors #8857 and #8956. but manifests as a silent hard crash rather than a python catchable error. which is harder to diagnose especially in --windowed, --noconsole applicaitons.

My Suggestions

1. Do not silently bundle openssl dlls discovered via ad-hoc PATH search without any validation. if pyinstaller cannot verify the discovered dll is ABI compatible with the qt tls backend (by checking version resource info or a maintained known good version list.) it should either skip bundling them and let qt handle it (qt handles by falling back to qcertonlybackend.dll or logging a clear warning) or at minimum warn loudly at build time. WARNING: bundling libssl-3-x64.dll found via PATH search at C:\Windows\System32\... this may not match the OpenSSL version expected by the bundled qt tls backend and can cause a runtime crash, so the developer knows to investigate before shipping.
2. Provide an opt-out flag like --exclude-openssl or documented excludes=[] pattern or anything.

Qt's related docs

"By default, an OpenSSL-enabled Qt library dynamically loads any installed OpenSSL library at run-time. However, it is possible to link against the library at compile-time by configuring Qt with the -openssl-linked option." https://doc.qt.io/qt-6/ssl.html

https://doc.qt.io/qt-5.9/ssl.html

"When openssl is loaded at runtime, Qt does not use ld. Instead, it checks directories in LD_LIBRARY_PATH, and some default locations (/lib, /usr/lib, /usr/local/lib, as well the lib32/lib64 variants)." https://forum.qt.io/topic/147823/wrong-version-of-openssl-used-when-deploying-application

This all supports treating those dlls as an environment provided, optional, version sensitive runtime dependency that qt itself never guarantees to ship. meaning pyInstaller bundling an unvalidated copy grabbed from PATH is working against qt's own dynamic loading design rather than with it.

Related Issues #8857 #8956 #7415

Thank you ❤️