QtCS2018 Third-Party Sources Policy and Security: Difference between revisions
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: | ||
[[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 | ||
* | * 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 ( | ** 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? | ** 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 | |||
* | * Continue follow minor upstream version | ||
Security issues | Security issues should block release | ||
* Existing releases: Release a patch | * Existing releases: Release a patch | ||
** Issue: Chromium releases | ** 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 | * 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 | * 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?
- To be investigated (QTBUG-68816)
- 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