Banning QNetworkAccessManager

[Volker Krause]

I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
akademy2019/public/events/135 on that subject.

On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
[...]
> Prior to now, i've taken the approach of advertising that
> QNetworkAccessManager is broken and needs a flag set within
> applications when used, however unfortunately this seems to have been
> an ineffective approach and cases of broken behaviour continue to
> appear (despite this brokeness being known about and advertised since
> back in the Qt 4.x series when this class was introduced)
> 
> Therefore, given the Qt Project is unlikely to change their position
> on this, I would like to propose the following:

The Qt Project is actually in favor of changing at least the redirection 
default to exactly what we want it to be.
https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and got 
approval both by Lars and one of the maintainers. It is merely stuck in 
dealing with the unit test fallout in Qt's CI that somebody has to take care 
of. Doesn't immediately help us of course, but claiming Qt is unwilling to 
change this is simply wrong.

> 1) That effective immediately, QNetworkAccessManager and it's children
> classes be banned and prohibited within KDE software, to be enforced
> by server side hooks.
> 2) That we fork QNetworkAccessManager and the associated classes
> within the appropriate Framework (to be determined), where the
> defective behaviour can then be corrected.

While this might solve the redirection problem, it brings us yet another then 
unmaintained HTTP implementation next to the one in KIO, which is a far bigger 
problem long term. We need less of those, not more.

To address the problem of people not using the correct defaults, I did propose 
a much less extreme approach in the above mentioned talk at Akademy, namely 
having a KNetworkAccessManager as a sub-class of QNAM in a low-tier frameworks 
that essentially just enables redirects and HSTS. QNAM's implementation isn't 
the problem after all, the defaults are.

Commit hooks warning about QNAM usage might still be a good idea, but as a 
warning only. Hard blocking QNAM-using code would block at least three repos I 
spend a lot of time on currently, none of which even talks to KDE servers.

If you need to take more drastic measures against code not doing this 
correctly regardless, you can do that my dropping the server-side workarounds. 
Yes, that would break the affected application possibly, but at least it would 
not cause massive collateral damage for the people using this correctly.

It would also help to know where specifically we have that problem, so we can 
actually solve it, and so we can figure out why we failed to fix this there 
earlier.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20200202/b7f0719e/attachment.sig>