qt: guard QSslConfiguration usage for QT_NO_SSL builds - #38
Open
Yaraslaut wants to merge 2 commits into
Open
Conversation
QtWebSocketBackend unconditionally included <QSslConfiguration>, took a std::optional<QSslConfiguration> constructor parameter, and stored one as a member. Qt builds configured without SSL define QT_NO_SSL and don't provide that type -- the Qt-for-WebAssembly build is the common case, since TLS is terminated by the browser and Qt ships no SSL backend there. Against such a Qt the header failed to compile: reproduced by forcing QT_NO_SSL against this project's own (SSL-enabled) Qt install, since Qt's own <QSslConfiguration> header self-guards on that identical macro regardless of how Qt was actually built -- "QSslConfiguration is an incomplete type" and a cascade of dependent errors, exactly the reported symptom. Guard every QSslConfiguration use behind #ifndef QT_NO_SSL: the include, the tls constructor parameter, the _tls member, and the two call sites that touch it. The constructor's arity itself now varies by build configuration, which the issue called out as a real trade-off -- the alternative (keeping the parameter and ignoring it) isn't available since the type doesn't exist to declare a parameter of. wss:// still works on an SSL-less build regardless of this change: in a WASM/browser deployment the browser terminates TLS before Qt's QWebSocket ever sees the connection, so the only thing genuinely unavailable is configuring TLS from C++ (client certs, pinning). qt_tls.hpp's helper functions remain a separate, opt-in header that still requires SSL support to compile -- unaffected in practice, since nothing calls it unless an application explicitly wants to configure TLS. Verified via a new try_compile() guard (tests/qt/CMakeLists.txt) that forces QT_NO_SSL against this project's normal Qt install: confirmed in both directions -- fails to compile against the pre-fix source (reproducing the exact reported error) and compiles cleanly against the fixed source. The existing (SSL-enabled) Qt test suite is unaffected: full rebuild and run against real Qt6, byte-for-byte matching the pre-change baseline. Follow-up noted, not fixed here (out of scope for this issue, which is specifically about QtWebSocketBackend): qt_websocket_server.hpp/.cpp has the identical unconditional <QSslConfiguration> dependency and would need the same treatment for a server to build against an SSL-less Qt. Closes #28 Signed-off-by: Yaraslau Tamashevich <yaraslau.tamashevich@gmail.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…uilds The original fix for #28 only guarded qt_websocket_backend.hpp/.cpp (the client). qt_websocket_server.hpp/.cpp compiles into the same morph_qt_impl target and still used QSslConfiguration and QWebSocketServer::SecureMode completely unguarded, so an SSL-less Qt build (including Qt-for-WebAssembly) still failed to build the target as a whole -- confirmed by reproducing the try_compile guard's own methodology directly against the server file before this commit. Guard the constructor's tls parameter/QSslConfiguration include the same way as the client, and treat hasTls as always-false in listen() under QT_NO_SSL (SecureMode itself isn't available). Extend the try_compile guard to compile both files together, including a manually-generated moc translation unit so the server's Q_OBJECT vtable resolves at link time (the client needs no such file -- it isn't a QObject). Signed-off-by: Yaraslau Tamashevich <yaraslau.tamashevich@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
QtWebSocketBackendunconditionally included<QSslConfiguration>, took astd::optional<QSslConfiguration>constructor parameter, and stored one as a member. A Qt built without SSL (QT_NO_SSL— the standard Qt-for-WebAssembly configuration, since the browser terminates TLS) doesn't provide that type, so the header fails to compile — the exact reported symptom, reproduced by forcingQT_NO_SSLagainst this project's own (SSL-enabled) Qt install (Qt's own<QSslConfiguration>header self-guards on the identical macro regardless of how Qt was actually built, so this reliably reproduces the failure without needing an actual SSL-less Qt).QSslConfigurationuse behind#ifndef QT_NO_SSL: the include, the constructor'stlsparameter, the_tlsmember, and the two call sites that touch it — matching the issue's primary suggested fix. The constructor's arity itself now varies by build configuration, the trade-off the issue explicitly named as unavoidable (there's no type to declare an ignored parameter of).wss://still works on an SSL-less build: the browser terminates TLS before Qt'sQWebSocketever sees the connection, so only configuring TLS from C++ becomes unavailable.qt_tls.hpp's helper functions remain a separate, opt-in header still requiring SSL support — unaffected in practice since nothing calls it unless an app explicitly wants to configure TLS.QtWebSocketBackendper the issue):qt_websocket_server.hpp/.cpphas the identical unconditional<QSslConfiguration>dependency and would need the same treatment for a server to build against an SSL-less Qt.Test plan
try_compile()guard (tests/qt/CMakeLists.txt+tests/compile_checks/qt_no_ssl_main.cpp) that forcesQT_NO_SSLagainst this project's normal Qt install. Verified in both directions: fails to compile against the pre-fix source (reproducing the exact reported error — "QSslConfiguration is an incomplete type" and the resulting cascade), compiles cleanly against the fixed source../build/tests/morph_tests— all 811 test cases / 8284 assertions pass, unmodified.Closes #28
🤖 Generated with Claude Code