Back from holidays, following up on the open points from this thread after discussing within The Qt Company:
> On 28 Jul 2022, at 18:13, Volker Hilsheimer <[email protected]> wrote: >> 2) The current *source* downloads for 5.15 (esp. the latest, 5.15.5) don't >> have a clean patch against them. >> >> Yes, one could always build Qt against a vanilla fixed Freetype, or replace >> (if that's easy/possible) the freetype in src/3rdparty/, that's not the >> point though. > > > The agreement is that KDE maintains patches like this for Qt 5 so that they > are available on top of the branches that are available to the Open Source > community. > > https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection > > This might require back-porting relevant patches from the LTS branch, to > which relevant people from the KDE community should have access. Open Source > users building Qt 5.15.2+ from source (which they have to, as there are no > official binary packages) would be expected to apply those patches first. As Albert commented, KDE in general doesn’t have access to the LTS branches, and even if some maintainers and KDE community members that are also TQtC customers have access to those branches, it would indeed be problematic wrt licensing, as Kevin pointed out. But all patches in Qt 6 are of course available to everyone under the relevant licenses. The idea of the “Qt 5 Patch Collection” maintained by KDE is that those are Qt 5-versions of patches made in Qt 6 that are considered relevant for KDE or other open source projects that are on Qt 5.15. This anyway requires in many cases back-porting those Qt 6 patches. >> 3) Most importantly: will the _future_ source downloads for 5.15 / 6.2 (e.g. >> 5.15.6, due in September) also be affected? I'd assume yes, if they're >> faithful to the "tagging" in the repositories, done a year ago. > > As of today, future Open Source packages from LTS branches such as 5.15 and > 6.2 come from the tags, with no additional patches applied. For Qt 5.15, the > KDE patches are expected to be the solution to this. > > This doesn’t help us for Qt 6 though, and the agreement is specifically about > Qt 5. On the other hand, for Qt 6 the issue is less problematic, as the > patches are available in a branch that is reasonably close to the LTS branch > (ie. the freetype patch in 6.3 applied cleanly against 6.2). > > But that doesn’t make it any more reasonable to make a source package with > known vulnerabilities available. The agreement with KDE is that the exact version of Qt that was released as commercial LTS is made available as a source-only package, with one year delay. So, the Qt 5.15.6 source package in September will be exactly what customers got as Qt 5.15.6, including a bundled freetype with vulnerabilities. This might make little sense, but it makes little sense to make a 5.15.6 that is different either, or a 5.15.6.2 with some patches applied. People can clone 5.15.6 from git, and people download and build software against old versions of Qt all day long, accepting that security patches or critical fixes might be missing. Since the LGPL source package of Qt 5.15.6 need to be configured and built explicitly anyway, follow Thiago’s recommendation to use system libraries whenever possible. Volker _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
