"In Qt through 5.14.1, the WebSocket implementation accepts up to 2GB for frames and 2GB for messages. Smaller limits cannot be configured. This makes it easier for attackers to cause a denial of service (memory consumption)." Possible patch: https://codereview.qt-project.org/c/qt/qtwebsockets/+/284735 Qt bug: https://bugreports.qt.io/browse/QTBUG-70693 It is not yet clear if upstream are planning to release a fixed 5.x or not due to API concerns. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-21035
Change is now upstream: https://codereview.qt-project.org/gitweb?p=qt%2Fqtwebsockets.git;a=commit;h=ed93680f34e92ad0383aa4e610bb65689118ca93 Is it backportable to 5.14/5.15? Do we want to do that?
(In reply to Andreas Sturmlechner from comment #1) > Change is now upstream: > > https://codereview.qt-project.org/gitweb?p=qt%2Fqtwebsockets.git;a=commit; > h=ed93680f34e92ad0383aa4e610bb65689118ca93 > > Is it backportable to 5.14/5.15? Do we want to do that? It is already in the 5.15 branch. Backporting to 5.14 doesn't make sense IMHO, as the patch introduces a new API that apps have to explicitly use, so backporting won't help with the CVE at all.
It will take some time to get this fixed then, if I had to guess I'd say we'll stabilise 5.14.2 before thinking about 5.15.x?
The KDE Release Service 20.04.3 stabilisation, on which this bug is going to depend (unless patching an unknown amount of stable packages) would put us at a start of stabilisation by the end of July.
(In reply to Andreas Sturmlechner from comment #4) > The KDE Release Service 20.04.3 stabilisation, on which this bug is going to > depend (unless patching an unknown amount of stable packages) would put us > at a start of stabilisation by the end of July. How are we looking now? I'm most concerned by bug 734600 and various other fixes which won't have been backported to 5.14.x.
See blockers.
(In reply to Andreas Sturmlechner from comment #6) > See blockers. * The qt-5.15 tracker has one stabilisation blocking it (texstudio) which I'm kicking off at the moment. * bug 726846 is VirtualBox, which does need a fix, but I think the blocker bugs on it aren't new. I'll look into it. * bug 728278 I have no idea about the importance of. I was just wondering if you had any additional context, fine if not. I did read the bugs!
Well, bug 734600 isn't fixed in 5.15.0 either so stabilisation won't do anything for it. It seems to me then that waiting for 5.15.1 and stabilise that is the better option (and always more stable than .0 anyway). Obviously all blockers need to be fixed before that can happen.
(In reply to Andreas Sturmlechner from comment #8) > It seems to me then that waiting for 5.15.1 and stabilise > that is the better option (and always more stable than .0 anyway). I feel like I agree with this. I mean of course we could backport all those Chromium fixes, but that will be one hefty patch... Qt upstream target for 5.15.1 is within August, but may or may not happen.
(In reply to Andreas Sturmlechner from comment #8) > Well, bug 734600 isn't fixed in 5.15.0 either so stabilisation won't do > anything for it. It seems to me then that waiting for 5.15.1 and stabilise > that is the better option (and always more stable than .0 anyway). > Right, but AFAIK there were other Chromium fixes in .0 anyway. But if that's the way it works with webengine (.0 is not very stable), it's of course fine. I'm not trying to be pushy, I just can't know unless I ask. I appreciate that Qt in general is quite a big system so it's useful to check my understanding is right. (In reply to Chiitoo from comment #9) > I mean of course we could backport all those Chromium fixes, but that will > be one hefty patch... > Yes, it'd be havoc. No need for that. > Qt upstream target for 5.15.1 is within August, but may or may not happen. Thanks for the info both. :)
(In reply to Sam James from comment #10) > (In reply to Andreas Sturmlechner from comment #8) > > Well, bug 734600 isn't fixed in 5.15.0 either so stabilisation won't do > > anything for it. It seems to me then that waiting for 5.15.1 and stabilise > > that is the better option (and always more stable than .0 anyway). > > Right, but AFAIK there were other Chromium fixes in .0 anyway. But if that's > the way it works with webengine (.0 is not very stable), it's of course fine. But either you are most concerned about bug 734600 or not, right? ;) It was a general comment re .0 releases, not specific to a single component. When we stabilise a version of Qt then QtWebEngine is just one part of it - we can't mix different versions. And if we give revdeps some more time to stabilise upon a new minor version that is also benefitial. (In reply to Sam James from comment #10) > I'm not trying to be pushy Don't worry about it. ;)
