Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On Thu, 7 Dec 2023 at 12:33, Giuseppe D'Angelo wrote: > * For how long is QNX going to support OpenSSL 1? Is OpenSSL 3 support > on the radar? Yes, it's on the radar for QNX 8, which is not released yet. > Is there an online resource showing their commitment at > maintaining it? Is there the possibility of just building+shipping > OpenSSL 3 outside of what it's provided by the base OS? Well, like it is on Linux distros, building and shipping it as a replacement is not easy, and building and shipping it alongside is not easy either. > * For how long are *we* going to support QNX and OpenSSL 1 on there? Until QNX 8 ships. > * What about other platforms? Maybe we should keep OpenSSL1 support in 6.5 throughout the lifetime of that LTS. > * Can we put this "contract" in the docs? Sure seems like it would be a good idea to revisit this for the next LTS in any case. Make that the point where we drop OpenSSL1 regardless of whether Blackberry has managed to ship QNX 8. That's different from doing it in a patch release, or backporting the drop to everywhere. We can plausibly say at that point that we'll just drop it. > > I don't quite follow why the revert "must" include making OpenSSL1 > > entirely an opt-in. > > That doesn't change anything in how we build our release packages, at > > the end of the day. > > Innocent users should just build with an OpenSSL3-enabled system. > > Innocent users may have their own build scripts that pull OpenSSL 1 and > build Qt against that, without realizing that they're playing with fire. > We should never expose users to insecure defaults, hence the opt-in > flag, and a build error if you ask for autodetection and only OpenSSL 1 > is found. Well, okay then. Patch it first so that the opt-in supersedes autodetection but the autodetection is still there, then patch coin so that everything in it that needs this uses the opt-in, then drop the autodetection. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
Il 07/12/23 13:55, Kevin Kofler via Development ha scritto: Why is that Qt's problem? Qt does not and cannot check that all security updates for all dependencies have been applied, even when using a branch supported by upstream, so I do not see why this case would be any different. Because 1) Qt should never use unsafe 3rdparty dependencies; 2) this is different code from the supported version. We're choosing to keep and maintain code, in Qt, in order to support a library that has reached EOL; 3) OpenSSL is by far the most security-sensitive code that we use. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
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
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
Giuseppe D'Angelo via Development wrote: > Innocent users may have their own build scripts that pull OpenSSL 1 and > build Qt against that, without realizing that they're playing with fire. > We should never expose users to insecure defaults, hence the opt-in > flag, and a build error if you ask for autodetection and only OpenSSL 1 > is found. Why is that Qt's problem? Qt does not and cannot check that all security updates for all dependencies have been applied, even when using a branch supported by upstream, so I do not see why this case would be any different. Especially because not every OpenSSL 1 out there is going to be insecure (due to LTS distros etc.). And neither is every OpenSSL 3 out there going to be secure. (Just because updates are available from upstream does not automatically mean they are going to be installed.) 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. And if the OpenSSL in use is actually insecure, that is something purely between upstream (OpenSSL) and downstream (the distro/OS, the application developer, and/or the end user), and hence completely out of the scope of Qt. Same as for any other third- party dependency. As long as Qt does not bundle an insecure OpenSSL, I do not see the issue here. Kevin Kofler -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
Hello, On 07/12/2023 09:50, Ville Voutilainen wrote: Well, this is straightforward in the sense that QNX doesn't support openssl3 yet. Dropping OpenSSL1 support is dropping support for TLS on QNX, and we don't want to do that. Sure, this is the premise of my mail, revert the change. What about the rest? * For how long is QNX going to support OpenSSL 1? Is OpenSSL 3 support on the radar? Is there an online resource showing their commitment at maintaining it? Is there the possibility of just building+shipping OpenSSL 3 outside of what it's provided by the base OS? * For how long are *we* going to support QNX and OpenSSL 1 on there? * What about other platforms? * Can we put this "contract" in the docs? I don't quite follow why the revert "must" include making OpenSSL1 entirely an opt-in. That doesn't change anything in how we build our release packages, at the end of the day. Innocent users should just build with an OpenSSL3-enabled system. Innocent users may have their own build scripts that pull OpenSSL 1 and build Qt against that, without realizing that they're playing with fire. We should never expose users to insecure defaults, hence the opt-in flag, and a build error if you ask for autodetection and only OpenSSL 1 is found. Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: S/MIME Cryptographic Signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On Thu, 30 Nov 2023 at 12:52, 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 > > > 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". Well, this is straightforward in the sense that QNX doesn't support openssl3 yet. Dropping OpenSSL1 support is dropping support for TLS on QNX, and we don't want to do that. I don't quite follow why the revert "must" include making OpenSSL1 entirely an opt-in. That doesn't change anything in how we build our release packages, at the end of the day. Innocent users should just build with an OpenSSL3-enabled system. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
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 OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
Il 30/11/23 11:49, Giuseppe D'Angelo via Development ha scritto: 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, Orthogonal but related, the patch kind of exposed a serious CI configuration problem: if SSL support gets accidentally disabled, the CI will still pass for a given configuration. I guess CI configurations are simply using autodetection, and if SSL stops being detected for whatever reason (say, we break a cmake file), then the build just proceeds under QT_NO_SSL. If that's the case, should just always enforce SSL presence at Qt configure time? (And should this enforcement be generalized to other important 3rd parties for which autotests exist? E.g. image formats.) Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Removal/deprecation of OpenSSL 1 in Qt
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 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". Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
