[Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

[Christian Gagneraud]

On 31 July 2018 at 23:45, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> On Dienstag, 31. Juli 2018 13:32:38 CEST Christian Gagneraud wrote:
>> On 31 July 2018 at 21:43, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
>> > On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
>> >> Hi,
>> >>
>> >> We used to build Qt-5.6.3 on and for Linux-i386.
>> >> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
>> >> fails with:
>> >>
>> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
>> >> In function 'ssl3_ChaCha20Poly1305':
>> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:
>> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
>> >> member named 'pIv'
>> >>
>> >>      aeadParams.pIv = (unsigned char *) additionalData;
>> >>
>> >>                ^
>> >>
>> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:
>> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
>> >> member named 'ulIvLen'
>> >>
>> >>      aeadParams.ulIvLen = 8;
>> >>
>> >>                ^
>> >>
>> >> Are there any special requirements,or actually is there a difference
>> >> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
>> >
>> > Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption
>> > and certicate checking but in 5.6.3 is only used for certificate
>> > checking. You can try using NSS 3.21, but note it will report most Google
>> > certificates as broken. You can also try removing libnss-dev in which
>> > case OpenSSL will be used for both, but that also means most Google
>> > certicates are reported as broken (because they objectively are signed by
>> > a too weak root).
>>
>> Thanks for all the details, greatly appreciated. I'll have to dig that
>> further, will report.
>>
>> > See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry
>> > pick it, though it might not be easy QtWebEngine also upgraded from
>> > Chromium 45 to 49 in the 5.6 series.
>>
>> What can I say other than:
>> Should this (Chromium 45 -> 49) be part of "patch" release?
>
> The question was: Do you want security fixes or not? The reason it was done is
> because we have upped our game on security fixes in webengine.

Can't you just backport security fixes, eg like Debian and OpenBSD do?
Adopting a new upstream MAJOR release b/c it contains security fixes is futile.
Every new MAJOR release brings up security fixes AND security regressions.
So while you fix something you introduce new, unknown security issues.

OK, I don't want to start a war, that's my basic understanding of
strict fixes vs blind upgrade.
I'm pretty sure that you've considered this problem 200 times before
coming with a decision.

I want security fixes, and ONLY security fixes.
To be honest my boss don't give a #&%%^#^* about security fixes, so i
just want a successful build, but that is another story

> Note 5.6.2 was the first and so far only time we have done this in a patch
> release, and I don't think it was worth the trouble. Since then I have
> prefered to recommend people using a more modern qtwebenigne with older
> qtbase. Note for instance, you can use up to QtWebEngine 5.9.x with the rest
> of Qt being 5.6. In fact if you use QtWebEngine on potentially hostile
> content, I would strongly recommend it as Qt 5.6.x is not updated as
> regularly.
>
> In fact using a newer QtWebEngine even if just the last one from 5.6.x with
> qtdeclarive being 5.6.0, might solve your problems.
>
>> To the point that now the "Qt Maintenance Tool" offers you to install
>> different patch release, like nobody trust they are actually
>> equivalent and ABI backward compatible as they used to be...
>
> I don't think that is fair. I know there has been a few mistakes, but they
> have usually been corner cases. When every other C++ project broke ABI due to
> C++11 Qt was able to maintain it due to how serious we have always taken it.
> But yes, you should always check if things still work when upgrading.

Maybe, there is a difference b/w runtime compatibility and build time
compatibility.
Because i have to build Qt myself (b/c Linux 32 is not supported any
more, even for commercial users), i'm hitting this build time
issues...

What drives me nuts in this story is that you still happily support WIN32...

Chris