On Thursday, 16 October 2025 01:48:31 Pacific Daylight Time Giuseppe D'Angelo
wrote:
>> 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.
Sometimes we checkout the upstream data and, possibly after fixing some
issues with that data, generate our own data from the upstream and
incorporate the results in our code-base. (The cases of this I know of
are CLDR and UCD, both from the Unicode Consortium.) Sometimes, when
doing this, I stumble on bogus data in the upstream source and report
bugs; once they're confirmed by upstream, I patch them locally as best I
can and use the result. Then I have to advise anyone doing an update to
patch them and check each later release for them until they're fixed
upstream.
>> So, before we go further, is this a real problem, and do we want to
>> address it?
Thiago Macieira (16 October 2025 16:35) wrote:
> I think a simple few steps are a good idea, though implementation may
> be difficult. Ideally we'd do a cryptographic check that the input is
> exactly what it purports to be; a visual review of the upstream link
> will tell us that it is a release in a known website and/or a tag in
> the upstream repository. One thing to watch out for are "random
> commits" because in GitHub, they can be in any fork instead of the one
> in the link.
>
> The big issue that I can see is the how: unless we start importing the
> tarballs themselves, cryptographic verification is difficult. Could
> the bot re-do the steps as specified (download tarball or git checkout
> the tag, cryptographically verify, then apply any pending patches) and
> verify that the result is identical to the commit?
Wherever it's possible to automate an update to a 3rdparty component, we
should aim to do so - it makes life so much easier for those doing the
updates. That would then let reviewers locally reproduce the update and
compare to what they're reviewing. In principle we could imagine a 'bot
that can reproduce to verify, or even to automate the updates - we that
do much of the updating would love that - but the sui generis
complications to many of our third-party components, or of the way we
use them and deploy them, might make such a 'bot hard to get right,
maintain and keep flexible enough to deal with all the complications.
But as long as there's a straightforward process for doing the update,
documented in an easily found ReadMe file or the qt_attributions.json
(which now supports "Comments": { "arbitrary: ["data"] } elements) we
can at least have a way for the reviewer to reproduce the work and
verify it matches (modulo any date-stamps saying when the update was
done).
I doubt we can really do better than that, although there may be some
components for which that is very compelling and easy to do.
Eddy.
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
