| Summary: | Qt5 GUI Library update from 5.15.2-4.3 to 5.15.2-4.4 broke dot/dash lines | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Ethan Merritt <sfeam> |
| Component: | RPM Packages | Assignee: | KDE maintainers <kde> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia |
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | qtbase5-5.15.2-4.4.mga8.src.rpm | CVE: | |
| Status comment: | |||
It looks like the last update was the timezone detection fix in Bug 29591. Assignee:
bugsquad =>
kde Having now downloaded and looked into the source rpm
qtbase5-5.15.2-4.4.mga8.src.rpm
I wonder if the error was introduced by this patch
CVE-2021-38593-2.patch
I do not know the context or motivation for this patch but I can see that under some conditions it replaces a dashed line with a solid line. The condition that it adds is
if (qFuzzyIsNull(extent) || ...previous test here...)
which means nothing to me but perhaps qFuzzyIsNull is not the right test.
This looks like this behaviour is intended to fix the security issue from CVE-2021-38593 https://codereview.qt-project.org/c/qt/qtbase/+/377942 https://codereview.qt-project.org/c/qt/qtbase/+/377941/2 https://github.com/qt/qtbase/commit/6b400e3147dcfd8cc3a393ace1bd118c93762e0c This is an upstream decision. Quote: "Avoid processing-intensive painting of high number of tiny dashes When stroking a dashed path, an unnecessary amount of processing would be spent if there is a huge number of dashes visible, e.g. because of scaling. Since the dashes are too small to be indivdually visible anyway, just replace with a semi-transparent solid line for such cases. " Yes, I understand the intent. But the test is apparently triggering incorrectly in some well-defined cases. I have not tracked back through the history of the changes involved, but I suspect the test is incorrectly assuming that an extent of zero is invalid. This would be incorrect. The dash pattern is defined as an even number of extent values, signifying a sequence of alternating draw/not-draw components. If the final extent is zero, this means that there is no gap between the final "draw" component of this pattern instance and the first "draw" component of the next pattern instance. So a final zero is legal. As I said, I have not tracked back through the changes to pin this down completely. The patch as included in that source rpm does not apply to the base source file, so there must have been intervening patches applied? I don't know exactly how your source rpms are set up. Would I have to download and apply patches in qtbase5-5.15.2-4.1 qtbase5-5.15.2-4.2 qtbase5-5.15.2-4.3 before this? The buggy fix was reverted and replaced with a better fix in qtbase5-5.15.2-18.mga9.src.rpm I can confirm that version works in Cauldron. The newer fix is 0218-Refix-for-avoiding-huge-number-of-tiny-dashes.patch >From 427df34efdcb56582a9ae9f7d2d1f39eeff70328 Mon Sep 17 00:00:00 2001 >From: Eirik Aavitsland <eirik.aavitsland@qt.io> >Date: Fri, 30 Jul 2021 13:03:49 +0200 >Subject: [PATCH 218/255] Refix for avoiding huge number of tiny dashes > >Previous fix hit too widely so some valid horizontal and vertical >lines were affected; the root problem being that such lines have an >empty control point rect (width or height is 0). Fix by caculating in >the pen width. It would be nice to have a working version in Mageia8 also. thanks, Ethan The fix is available for 6 months in KDE's qt5 repo: https://invent.kde.org/qt/qt/qtbase/-/commit/427df34efdcb56582a9ae9f7d2d1f39eeff70328 Why Qt5 is not yet switched to KDE's branch? Do you really like to cherry pick every single patch manually? Are there any drawbacks of such switching? Qt from cauldron with with KDE branch. We should do this for mga8 too. |
Description of problem: Horizontal and vertical dashed lines with linewidth > 1 come out solid. This is true both for the predefined dash patterns set by currentPen.setStyle(Qt::PenStyle(style)) and custom dash patterns set by currentPen.setDashPattern(dashpattern). Lines at other angles seem unaffected Everything was fine in release lib64qt5gui-5.15.2-4.3 but the upgrade to 5.15.2-4.4 broke all application programs using dashed lines. In my case this is gnuplot but the issue is clearly a library problem. It is still broken in the lastest update 5.15.2-4.5 in both Mageia 8 and in Cauldren. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. downgrade to lib64qt5gui-5.15.2-4.3 or earlier 2. run application program (gnuplot in my case) that draw dashed lines. E.g. plot 0 with lines linewidth 2 dashtype '.-' or plot sin(x) with impulse linewidth 3 dashtype 3 this will produce a plot with a horizontal line .-.-.-.-.- at y=0 or a set of vertical dotted lines 3. upgrade to lib64qt5gui-5.15.2-4.4 run the application again, same test commands test 1 produces a solid horizontal line test 2 produces a set of vertical solid lines