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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development