[Development] [Announce] Security advisory: Freetype in Qt

[Volker Hilsheimer]

Hey,

> On 28 Jul 2022, at 17:31, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
> 
> Hi,
> 
> On 27/07/2022 22:23, Thiago Macieira wrote:
>> On Wednesday, 27 July 2022 11:47:20 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> Right now, if one selects "LTS" and "Latest releases" (and *not*
>>> "Archive"), one gets
>>> 
>>> * 6.3.1
>>> * 6.2.4
>>> * 5.15.2
>>> 
>>> all of which are bugged AFAICT?
>> Non-commercial customers shouldn't even see the option for LTS, since it's not
>> LTS for them. There should only be "Latest releases".
>> Yes, it means that to find Qt 5, you'll need to go look in the Archive.
> 
> Trying to summarize:
> 
> 1) The current opensource binary downloads, marked "LTS" / "Latest releases", are all bugged. Given they will never get a binary update for 5.15 or 6.2, I don't think it makes any sense to keep them available under those labels -- they should be in "Archive" or so.


Agree, marking anything in the installer as LTS for Open Source users is at the very least misleading. I’ll follow up on that with our installer team once people are back from holidays.


> 6.3.2 should be released in a few weeks and I'm assuming will contain the fix in question? (As well as being provided as binary downloads.)


Yes, https://codereview.qt-project.org/c/qt/qtbase/+/423391 is the cherry-pick into the 6.3 branch, and there is no 6.3.2 tag set yet. There will be binary downloads for Open Source users as well.


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


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


> Are further patches (that apply against them) going to be published? Or will it be the case that 5.15.6 isn't really going to be a "release", but mostly something like "5.15.6's source is now publicly accessible"?


As of now, we make a tar-ball with the sources available. E.g. https://lists.qt-project.org/pipermail/development/2022-June/042659.html

Since that tar-ball comes from a dedicated tag (v5.15.5-lts-lgpl in the above case), we might perhaps apply security patches at least in the Qt 6 LTS branches before tagging. I’ll discuss options with the release team after the break.


> (To me it makes zero sense to "release" something with known vulnerabilities.)


Agree.

Volker