QtCS2018 Third-Party Sources Policy and Security: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Created page with "Third party sources policy and security Host: Thiago Macieira Notes: Kai Koehne Motivation: Intel Clear Linux has the policy to fix any CVE within 24 hours * Hard to do for...")
 
(stray duplicate word)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Third party sources policy and security
[[Category:QtCS2018]]
 
Host: Thiago Macieira<br />
Host: Thiago Macieira
Notes: Kai Koehne
Notes: Kai Koehne


Motivation: Intel Clear Linux has the policy to fix any CVE within 24 hours
Motivation: Intel Clear Linux has the policy to fix any CVE within 24 hours
Line 11: Line 9:
* We should aim for using system libraries for all image formats
* We should aim for using system libraries for all image formats
* Work started already for macOS
* Work started already for macOS
* Can we do this for Windows (AP)
* Can we do this for Windows? (AP)


Can we just rely a lot more on system libraries?
Can we just rely a lot more on system libraries?
* Linux should be fine
* Linux should be fine
* Windows, macOS, Linux: vcpackage?
* Can we use [https://blogs.msdn.microsoft.com/vcblog/2018/04/24/announcing-a-single-c-library-manager-for-linux-macos-and-windows-vcpkg/ Vcpkg] as a common package management system?
** To be investigated (AP)
** To be investigated ([https://bugreports.qt.io/browse/QTBUG-68816 QTBUG-68816])
* Alternative: Build ourself, but as separate library
* Alternative: Build ourself, but as separate library, so that we can update it separately


Some are deeply entangled
Some are deeply entangled
Line 28: Line 26:


* If not, use bundled copy
* If not, use bundled copy
** Maybe provide a configure option for that? --no-bundled-libraries
** Maybe provide a configure option for that? -no-bundled-libraries, making all bundled libraries opt-in (see [https://bugreports.qt.io/browse/QTBUG-68815 QTBUG-68815])


We should aim for always shipping latest version available
We should aim for always shipping latest version available
** At FF time latest (minor) update
* At FF time latest (minor) update
** Coninue follow minor upstream version
* Continue follow minor upstream version


Security issues (CVE) should block release  
Security issues should block release  
* Existing releases: Release a patch
* Existing releases: Release a patch
** Issue: Chromium releases 50 security advisories per month!
** Issue: Chromium releases dozens of security related patches per month!
** How to decide what is really critical? Sometimes non-critical issues escalate over time ...
** How to decide what is really critical? Sometimes non-critical issues escalate over time ...


Line 45: Line 43:
How often should we do patch set releases?
How often should we do patch set releases?
* Current goal: Patch releases 3-4 weeks
* Current goal: Patch releases 3-4 weeks
* We cannot do new stabel patch releases for every single upstream version
* We cannot do new stable patch releases for every single upstream version
* -> It should be enough to provide patches for security fixes
* -> It should be enough to provide patches for security fixes


Line 60: Line 58:
* Should it need security updates too?
* Should it need security updates too?
* Some customers might require that...
* Some customers might require that...
* Clashes with some security downstream security policies
* Clashes with some downstream security policies

Latest revision as of 09:16, 5 July 2018

Host: Thiago Macieira
Notes: Kai Koehne

Motivation: Intel Clear Linux has the policy to fix any CVE within 24 hours

  • Hard to do for third-party code that's entangled in Qt

Notorious offenders: Image plugins (eg. libtiff)

  • We should aim for using system libraries for all image formats
  • Work started already for macOS
  • Can we do this for Windows? (AP)

Can we just rely a lot more on system libraries?

  • Linux should be fine
  • Can we use Vcpkg as a common package management system?
  • Alternative: Build ourself, but as separate library, so that we can update it separately

Some are deeply entangled

  • FreeBSD strtoll and strtoull
  • We become responsible and need to issue a separate CVE

Discussion for Rules

  • If system library is found, use system library
    • Agreed
  • If not, use bundled copy
    • Maybe provide a configure option for that? -no-bundled-libraries, making all bundled libraries opt-in (see QTBUG-68815)

We should aim for always shipping latest version available

  • At FF time latest (minor) update
  • Continue follow minor upstream version

Security issues should block release

  • Existing releases: Release a patch
    • Issue: Chromium releases dozens of security related patches per month!
    • How to decide what is really critical? Sometimes non-critical issues escalate over time ...

First step is to actually document what we ship

  • We got better there, but still miss integration with configure to actually show what is included
  • Let's not forget the majority of our customers, who won't update Qt weekly, let alone monthly!

How often should we do patch set releases?

  • Current goal: Patch releases 3-4 weeks
  • We cannot do new stable patch releases for every single upstream version
  • -> It should be enough to provide patches for security fixes

Assign maintainers for Third Party Components

  • Some modules are unmaintained
  • Should we have dedicated maintainers for all third party modules?
    • Hard to get already maintainers for existing modules
    • This is for much more limited scope though
  • Monitoring system for upstream CVE's?
    • Yocto has a system

Qt Creator

  • Should it need security updates too?
  • Some customers might require that...
  • Clashes with some downstream security policies