qt-everywhere-opensource-src-5.15.4

[pierre]

New point version made opensource. The kf5 patchset has to be redone.

[ken@…]

Objection, your honour!

1. If you update to 5.15.4, you will need to rebuild qtwebengine to link to it. Not a big deal, just a reminder.

2. As with 5.15.3, AFAICS we have all the required kf5 patches up to January this year, and I've not yet seen anything which suggests later patches are necessary for any reason (e.g. fixing newer CVEs, or wayland on nvidia).

If updating those patches against 5.15.2 (sic) it is just a matter of finding any newer patches. But if somebody really wants to use 5.15.4 as the basis (and that is still a year old, unlike the kf5 patches) they will need to remove whichever patches have been shipped in free 5.15.3 and 5.15.4. To me, that sounds like a waste of effort, but details of what was included, and how I got there, should be in ​https://www.linuxfromscratch.org/~ken/qt5/ -see the README* and preparing* files (only one of each).

Anybody is free to spend time on that if they wish, I'm not going to at the moment.

[pierre]

Looks like I am unable to find release notes... For the patchset, let me show what I have done. I do not mean to tell that this is the only way, but this has worked for me:

$ git clone https://invent.kde.org/qt/qt/qt5.git
$ cd qt5
$ git submodule init
$ git submodule update

A login is asked for qthttpserver... Just type <return>. This module is not downloaded, but is not needed. Remove it completely, then proceed to make the patch:

$ git submodule deinit qthttpserver
$ git diff v5.15.4-lts-lgpl..origin/kde/5.15 --submodule=diff >../path/to/patch

Edit the patch to remove what concerns qtpim (use the search string: "^Submodules" which separates various submodules). Remove also what concerns qtwebengine. Beware that qtwebengine has itself submodules. Be careful to remove everything.

Then grab the tarball, expand it, and verify that the patch applies.

[ken@…]

It looks as if recent git has improved the handling of submodules (I ended up recloning qtwebengine, but there have not been any subsequent chromium commits for me to check if that assumption worked), so I guess that will work.

The only vulnerability fix I'm aware of at the moment (mind like a sieve, I might have forgotten another) was in qtsvg, which maybe got into 5.15.4:

diff --git a/src/svg/qsvghandler.cpp b/src/svg/qsvghandler.cpp
index b3d9aaf..9dac05c 100644
--- a/src/svg/qsvghandler.cpp
+++ b/src/svg/qsvghandler.cpp
@@ -673,7 +673,8 @@ static qreal toDouble(const QChar *&str)
             val = -val;
     } else {
         val = QByteArray::fromRawData(temp, pos).toDouble();
-        if (qFpClassify(val) != FP_NORMAL)
+        // Do not tolerate values too wild to be represented normally by floats
+        if (qFpClassify(float(val)) != FP_NORMAL)
             val = 0;
     }
     return val;
@@ -3046,6 +3047,8 @@ static QSvgStyleProperty *createRadialGradientNode(QSvgNode *node,
         ncy = toDouble(cy);
     if (!r.isEmpty())
         nr = toDouble(r);
+    if (nr < 0.5)
+        nr = 0.5;
 
     qreal nfx = ncx;
     if (!fx.isEmpty())

That's about the only thing I can suggest to check.

Certainly, my method based on what was initially documented (using git format-patch) pulled out a lot of things which were not wanted (already in 5.15.2) or did not apply (soem tests stuff, which doesn't matter, and some mac stuff). So I hope your method works better than mine, if it does it will simplify the monolithic build.

[pierre]

The patch above has been applied to 5.15.4, so no need to worry. I'm certain that a lot of the stuff in the patch is not very useful, but kde wants them... Fixed at 195cc2f996.