On 30/11/23 12:49, Giuseppe D'Angelo via Development wrote:
Hi,OpenSSL 1 has reached EOL last September:https://www.openssl.org/blog/blog/2023/09/11/eol-111/Qt has supported OpenSSL 3 for a while, and so last week I pushed a patch to drop OpenSSL 1 support from Qt. "This has made a lot of people very angry and been widely regarded as a bad move." It turns out that not every platform officially supported by Qt ships OpenSSL 3 yet. Some of these platforms are promising to maintain OpenSSL 1 for a little while longer, for instance Ubuntu 20.04 LTS:https://canonical.com/blog/running-openssl-1-1-1-after-eol-with-ubuntu-pro
See this thread started by Albert on the kde-distributions ML about the same issue https://mail.kde.org/pipermail/distributions/2023-November/001459.htmlTypically when you plan to support EOL software, you do the extra work on your own, that should include e.g. patching Qt to get that support back, and you maintain the patches to Qt code on your own too. That is my understanding of how corporate Linux support works, and it's confirmed by what Jan Grulich posted in a reply to the above KDE ML thread: https://mail.kde.org/pipermail/distributions/2023-December/thread.html
(pipermail doesn't show links to the rest of the thread if it spans multiple months).
How to move forward from here: "revert the patch", sure, but also not so fast: * First and foremost, I'd like a semi-formal insurance from Qt SSL maintainers that they're willing to maintain OpenSSL 1 code in Qt as long as needed. This should be done publicly, in docs + blog posts, because users are going to depend on this information. * For "how long" is that exactly? Also a very good question. Can we gather 1) which supported platforms are still offering only OpenSSL 1, and 2) for how long do they plan to support OpenSSL 1, and 3) for how long Qt would like to support these platforms? (Basically, assessing whether the "insurance" above is realistic)
[...]
* Then, a plain revert isn't a good idea either: the whole point of the original commit is that using OpenSSL 1 is outright dangerous if you don't know what you're doing. (Using unmaintained security-sensitive code is a terrible idea). Therefore, a revert must also include make OpenSSL 1 entirely opt-in (cmake switch), and not using any automatic detection whatsoever: users of Qt should never ever be enabling it "by accident".
Just stating the obvious: I agree, must be opt-in with a clear disclaimer "You're on your own, if it breaks, you get to keep the pieces".
[...] My 2p's worth. Regards, Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
