From a1e9fe543b5a59d444c8571731a267910e909f39 Mon Sep 17 00:00:00 2001 From: Volker Hilsheimer Date: Tue, 21 May 2019 17:49:17 +0200 Subject: QUIP 15: The Qt Project Security Policy This is mostly a copy of the existing document at [1], transformed into reStructuredText, with some spelling issues fixed, and prefixed with a short introduction to outline the purpose of the document. [1] https://wiki.qt.io/Qt_Project_Security_Policy Change-Id: I7520c2b314f271b16bcc07821fd7e3cc3c98591b Task-number: QTWEBSITE-862 Reviewed-by: Lars Knoll --- quip-0015-Security-Policy.rst | 90 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 quip-0015-Security-Policy.rst diff --git a/quip-0015-Security-Policy.rst b/quip-0015-Security-Policy.rst new file mode 100644 index 0000000..d47deb2 --- /dev/null +++ b/quip-0015-Security-Policy.rst @@ -0,0 +1,90 @@ +QUIP: 15 +Title: Qt Project Security Policy +Author: Volker Hilsheimer +Status: Active +Type: Process +Content-Type: text/x-rst +Created: 2019-05-21 +Post-History: https://lists.qt-project.org/pipermail/development/2019-May/036030.html + +Qt Project Security Policy +========================== + +This QUIP documents the security policy of the Qt project. The goal is to inform +users of Qt about how the project handles security issues in Qt, and to document +processes that enable contributors to the Qt project to participate in the +prevention and handling of suspected vulnerabilities. + +Reporting Security Issues +------------------------- + +Security issues should not be reported via the normal bugreports.qt.io tracker, +but should instead be sent to security@qt-project.org + +What Happens When an Issue is Reported? +--------------------------------------- + +* Email sent to security@qt-project.org is delivered to a 'core security' team + of developers. +* The 'core security' team starts by determining if an issue falls within the + purview of an existing Maintainer, if so then they should inform this + Maintainer. +* Whilst Maintainers are responsible for addressing any security issues in the + code they maintain, the 'core security' team is responsible for ensuring + that the issue is addressed, and that the security policy is followed. +* The 'core security' team is not responsible for fixing issues, merely for + managing the process. +* Any issue reported to security@qt-project.org should receive (at least) an + acknowledgment of receipt within 48 hours. +* Any issue reported should be triaged to determine the risk it poses to end + users of Qt within 96 hours of the initial report to security@qt-project.org. +* If there is no response in the above time frame (this should never happen), + then the reporter should contact the Chief Maintainer directly. +* Any issue determined to be high risk should be immediately reported to the + Chief Maintainer by the security team. + + +What Versions of Qt are Supported? +---------------------------------- + +Fixes are only guaranteed to be provided for: + +* The latest released version. +* The preceding minor version. + +Fixes for earlier versions (such as 4.8, 5.0, etc.) may be provided, but the +Qt project makes no commitment to do so. Other groups such as The Qt Company +may choose to make such fixes available, but that is outside the scope of the +Qt project. + + +How will Issues be Disclosed? +----------------------------- + +* Security issues will be disclosed by an email to the announce@qt-project.org + mailing list. +* All members of the 'core security' team must have posting rights for the + announce@qt-project.org list for this purpose. +* All security announcements will be made on behalf of the Qt Project, though + credit to those responsible for identifying and addressing the issue should + be made. +* The security announcement should describe: + * The security issue. + * How and when it will be addressed. + * Sufficient technical detail to allow users of Qt to determine the impact + on their applications. + * How to fix or work around the issue in existing installations and + applications. +* If an issue requires clarification beyond the security announcement then this + can be done using the development mailing list or the interest mailing list. + This is not expected to be required for all security announcements, and does + not replace the formal notification via the announce mailing list. +* Where possible, early notification should be sent to packagers such as + distribution contacts. These notifications should be considered privileged + information. A security-announce list for distribution contacts will be used + for this purpose. +* Membership of the security-announce mailing list should be kept small, and + granted only by agreement with the 'core security' team. This membership can + be revoked at any time, with no explanation required. +* Where possible, packagers should be informed directly of which SHA1s they + should cherry pick in order to get a security fix. -- cgit v1.2.3