Hi,QUIP 4 https://contribute.qt-project.org/quips/4 documents that module maintainers should track 3rd party components in Qt, and make sure to update them before the release. It doesn't delve into the specifics about how we do these updates.
In https://bugreports.qt.io/browse/QTQAINFRA-7367 I argue that any change done to software in 3rdparty/ should trigger the security bot to flag the change as security-sensitive. This should be independent from the security classification of the particular 3rdparty: once malicious code is in Qt, all bets are off.
However, I also argue that this is insufficient, and we need a more structured way to handle such updates.
In particular, the problem is that we don't really review these commits in depth -- as long as they come from a maintainer, they compile, and the commit message makes sense, we usually just approve them.
But this offers the opportunity for a compromised actor to sneak malicious code into Qt. I'm specifically referring here to the import step in Qt, not to an attack against the upstream libraries.
I'd like to discuss some concrete mitigation strategies for this issue.Ideally, there should be a validation of all the 3rd party code shipped with Qt as part of the release process. However this doesn't look straighforward: we fetch libraries from many different repos, we have custom build scripts, we just copy a subset of the files, sometimes we patch them. So we can't just compare 3rdpart/foo/ with a fresh tarball of libfoo.
So, before we go further, is this a real problem, and do we want to address it?
Thanks, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence
smime.p7s
Description: Firma crittografica S/MIME
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
