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

[Giuseppe D'Angelo]

Hi Thiago,

thanks for starting these conversations on the mailing list. I'll miss 
this QtCS, so this is great for me and for whomever else won't be able 
to attend.

Il 08/06/2018 22:10, Thiago Macieira ha scritto:
> There's a session scheduled for Monday (unless it gets moved). Here's what I
> will propose.
> 
> 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;

* 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);

* 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).

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).

* libraries that are usable as-is from upstream and of which there's a 
reasonably recent version available in major distributions.


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


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?

> 
> 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?

> 
> 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..

> 4) No patches are necessarily issued for fixes to libraries that can be used
> as system libraries. But all releases from that point on will be patched.
> 
> 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 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)?

> 
> 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)?

Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | 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 - The Qt, C++ and OpenGL Experts


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180610/590b7177/attachment.bin>