[Development] Removal/deprecation of OpenSSL 1 in Qt

[Ahmad Samir]

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.html

Typically 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231205/1d291488/attachment.sig>