[Development] QtCS 2018: Third-party and security policy

[EXT Eike Ziller]

> On 10. Jun 2018, at 22:48, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Sunday, 10 June 2018 18:17:31 IST Giuseppe D'Angelo wrote:
>>> 0) Where not really necessary, delete the third-party code and force the
>>> use of a system library (see assimp discussion, can be applied to
>>> qtimageformats too).
>> 
>> What's the definition of "necessary" here? We're having several
>> variations of 3rd party code (list probably not complete):
>> 
>> * code that got "extracted" from upstream libraries (e.g. strtoll-like
>> functions from FreeBSD), and most importantly doesn't exist in a
>> suitably packaged format;
> 
> That's necessary.
> 
>> * libraries that received heavy modifications by Qt (this used to be the
>> case for harfbuzz-ng, not sure if it's still like that) and thus, the
>> upstream version simply isn't usable as-is (we might even say that there
>> isn't an upstream version);
> 
> That's also necessary, but we should strive harder to upstream those changes 
> so we can have an option.
> 
>> * libraries that are usable from upstream, but of which we require a
>> version so recent that it's not included in major distributions (e.g.
>> this used to be the case for PCRE2, it's probably still the case for
>> some XCB code).
> 
> Those two are necessary. But as a counter example, libdouble-conversion was 
> needed at a recent version, but could be disabled, if certain other system 
> functions were present. Unfortunately, they're not on Linux.
> 
>> This opens the can of worms of defining which distributions to include
>> in this definiton (for Linux, I'd include only LTS distributions: latest
>> Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...;
>> also, on non-Linux, one has to check things like vcpkg / choco on
>> Windows and homebrew on macOS).
> 
> Right, those are points for consideration.
> 
>> On an orthogonal level, we also need to classify the usage of our library
>> 
>> * we can't build without it
>> * we can build without it, but this would disable this feature of
>> importance X
> 
> That's my point above. If we can't build without it, then it's necessary. If 
> we can build without it, we could disable it.
> 
> For example, we can build without XCB. Do we want to? On the other hand, which 
> distribution doesn't have it?
> 
>> Should we build this sort of matrix?
>> 
>>> 1) Third-party bundled should be opt-in, not opt-out. That is, the system
>>> library always takes precedence, if found.
>> 
>> Isn't this already the current behaviour of Qt's configure scripts?
> 
> No.
> 
>>> 2) Qt Project sources always ship the latest third-party sources available
>>> one week before the Qt release. The grace period is just so that we can
>>> release the RC that passed QA. Every feature release receives updates to
>>> the latest and greatest upstream; every patch release receives updates in
>>> the same patch- series by upstream, if such exists. Release Management
>>> will put this as a P1 requirement for the release, like the changelog,
>>> header check, BC check, etc.
>> One week before the Qt release or one week before the RC? In other words
>> if a library gets an update after the RC is released, and the update
>> isn't related to any security issue, what do we do?
> 
> One week before release. That is, if there's a new release by upstream the 
> same day we released an RC, then we will need a new RC. If it's updated after 
> the RC is released and the released RC is not going to be rev'ed by other 
> reasons, then we don't update.
> 
> Regardless of reason why upstream released. They're fixing bugs

And introducing new ones, potentially including security bugs. I think just updating to a new version regardless of reasons is a bad idea.
A delay of the release because of an 3rd-party update also has the potential to create a cascading required update effect.

Take an example for Qt Creator:
If we are about to release Qt Creator with LLVM/Clang 6.0, and LLVM/Clang 6.1 is released, this has good chances to introduce bugs. Aside from that, updating the binaries that we ship is an effort, since they are profile optimized etc etc.
If instead LLVM/Clang 7.0 should be released, Qt Creator might not even compile anymore. The probability that some functionality is broken increases even more.
After we fix all these issues (it’s 1-2 weeks later now than the original schedule), a new version of sqlite is released.

> and not all 
> security-worthy bugfixes are noted as such.
> 
>>> 3) Qt Project sources receive a patch for a security fix in a library that
>>> cannot be built as a system library. That's the case of the bundled
>>> FreeBSD
>>> sources or TinyCBOR or right now with Qt Creator's sqlite. We do this
>>> within one week of the fix, even if it is high Summer in Finland. All
>>> releases after this point will contain the patched version.
>> 
>> This requires a commitment above my powers..
> 
> I know. That's why I am bringing this to QtCS.
> 
> I am setting the bar high enough so that new maintenance of third-party code 
> is unwelcome enough that people will not do it. Right now, it's too easy to 
> import some code into src/3rdparty and forget about it. We can't have that.
> 
>>> 5) Qt Project binaries containing third-party code are re-released every
>>> time the code has a fix for a CVE that isn't in what we're shipping. We
> 
> Read: for a CVE that *is* in what we're shipping. I meant to say that if the 
> particular line of code is not compiled, then we don't need to go through this 
> process. But prove you didn't compile it (such as .c source not listed in 
> SOURCES). This excludes "Qt can't reach that code but it was compiled" because 
> people do crazy things, like calling into those libraries supplied with Qt 
> directly from their code.
> 
>>> do this within one week of the fix, same conditions. Note this applies to
>>> the "gnuwin32" dir in qt5.git too.
>> 
>> Re-released keeping the same version of Qt? And which binaries are
>> re-released, the ones currently supported (e.g. right now 5.6.latest,
>> 5.9.latest, 5.11.latest)?
> 
> Everything affected and supported in whichever way is easiest to re-release. 
> If we have an RC for a new patch release ready to go, then so be it. If we 
> need to apply the patch and release a "5.11.0-2", then we do that. (we can do 
> dashes in binary releases)
> 
> So you're right: if an issue is found affecting the code in 5.6 and 5.9, but 
> not 5.11 because 5.11 has a new enough copy, then we rebuild 5.6 and 5.9.
> 
>>> 6) Each third-party bundled library must have an official maintainer and
>>> one deputy who know how to update it and are tracking that library's
>>> security advisories. They'll both be added to the Qt Security Team. They
>>> have to inform the Security Team if they are going to be completely
>>> unavailable for more than a week. If both are going to be unavailable,
>>> they need to ensure there's someone who is tracking the library.
>>> 
>>> 	Corollary: existing code that cannot meet this requirement will be
>>> 	deleted from the Qt Project sources.
>>> 
>>> I know this is harsh, but I think it's necessary
>> 
>> Mind elaborating why do you think it's necessary? Are we trying to
>> educate Qt users to proper security policies and workflows? Are there
>> business reasons for this (e.g. people not choosing Qt, or Qt getting a
>> bad reputation, etc. because of our lax security policy)?
> 
> I meant the harshness about the deleting of sources no one maintains and no 
> one knows how to update, as well as the need to track CVEs. If we don't track 
> CVEs, we may be shipping code that is vulnerable and not know it.
> 
> I'm not trying to educate users. If someone downstream from us has more lax 
> policies, it's their business. It's their liability if something happens.
> 
> My problem is those downstream who have more strict policies. Our not 
> complying to them could mean Qt cannot be used. It could mean loss of 
> business, but I of course can't get into details here.
> 
> It's possible to not be so strict inside Qt and also comply with strict 
> security policies downstream if the code in question is a system library or if 
> we issue a parallel CVE every time the non-unbundleable code we ship is 
> affected. This allows downstreams to apply the fix, even if we don't.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B