[Development] Proposal: move Qt provisioning scripts and 3rd party components into a dedicated repo

[Thiago Macieira]

On Thursday, 14 July 2022 02:23:47 PDT Volker Hilsheimer wrote: 
> As mentioned, this would be a gradual process, one 3rd party dependency at a
> time and figuring out what it takes to make this work on all platforms.
> Some 3rd party code might have to stay where it is today.

And I am partly to blame for that (tinycbor).

> What do you think?

Thank you for sending this, Volker. As Alexandru reminds us, this is not a new 
discussion. We had planned on doing this for 6.0, but didn't get it all the 
way to the end. Does anyone have a conclusion of why we didn't do it for 6.0? 
Was it only lack of time, or did we try and come to difficult problems? If so, 
can you summarise what they were?

Disclaimer, Volker is sending this because I brought it up again, in the 
context of a security issue. And this is an important reason why we should do 
this, so let me expand: right now, by bundling the sources of third party 
libraries into our sources, we make it difficult for Regular Joe users to know 
just which ones they are using and thus if there are security issues 
applicable to their applications. All of this is compounded by there being 
binary packages (which I'm not sure are a Qt Project deliverable or if they 
are a Qt Company deliverable), but let's focus on source only right now.

Many of the third-party content we use are very low-level libraries that are 
subject to security issues themselves. Often, they don't apply to how Qt uses 
those libraries, since we only use them in a restricted context, but automated 
vulnerability-scanning tools won't know that. So if a customer is told "zlib 
has a security vulnerability with severity High", they may need to patch it. 
Speaking from an Intel perspective, it is far easier to simply patch than to 
get an exception / exemption saying "this doesn't apply to me".

This can be worse when the vulnerability DOES apply to them but the scanning 
tool doesn't know that it does because the code in question is buried inside 
of the Qt sources. The tool may simply treat all of Qt as "Qt", or fail to 
recognise this content because we've patched it somehow (such as by removing 
its native build system and using the CMake integration).

By unbundling from inside our sources, we make it obvious that such a 
component is there. We make it easy to replace it too, if we stop patching it.

This applies to us, not just customers. When we do get a notice saying that a 
given third party has a security vulnerability disclosed, we can much more 
easily update it throughout the CI. It can also easily roll out to binary 
packages, but I won't make that determination.

This also applies to Open Source licence compliance. I handle this for Intel 
every time Qt comes up, but all other companies that aren't Intel don't employ 
a maintainer in the Qt Project that knows this inside and out. They need to 
know what libraries they're using to know that they're all compatible with 
each other, and to list them in the necessary documentation. We do help them 
with the "qt_attribution.json" files of course, but unbundling makes it 
obvious.

The other aspect is binaries. We've also just received a request on how to use 
the bundled zlib in user code. The answer is: Don't. The bundled libraries are 
for Qt's use only and if you want to use it, you must have the regular library 
that your content can use. And if you're going to do that anyway, then you 
will likely want to avoid having two copies.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering