On Thursday, 7 December 2023 04:55:48 PST Kevin Kofler via Development wrote: > Qt should just use whatever OpenSSL is installed on the system and be done > with it. Chances are that any OpenSSL 1 it finds will be from some LTS > distro with backported security fixes anyway.
I only agree partially with this statement, based on the previous paragraph. The problem is that OpenSSL 1 and 3 have differing APIs, so supporting both means extra work for us. It's not a matter of just washing our hands, even if OpenSSL were "just another third-party dependency" -- it isn't, it's the single most security-relevant one. In fact, this is closer to support for Windows 9x/Me back in the day, where keeping this added to the maintenance of the other, more recent and more relevant configurations. So here's what I propose as a compromise: * we keep the code alive in the repository, for now * we set a deadline for re-review, based on cost of maintenance and relevance * we make it clear to users we do not test this, not even that it compiles * but we advise we will take care of security issues stemming from our own code as we've always done That would put OpenSSL 1 support in the same bucket as FreeBSD or HaikuOS or Sparc processor support: whoever is using this[1] must supply patches. I propose we re-review once a year. [1] that may include the Qt Company if their commercial interests call for it. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
