diff options
authorVolker Hilsheimer <>2019-05-21 17:49:17 +0200
committerLars Knoll <>2019-07-05 11:29:41 +0000
commita1e9fe543b5a59d444c8571731a267910e909f39 (patch)
parentf5e2959fbd8c307fe4bc374dee5574b3568178be (diff)
QUIP 15: The Qt Project Security PolicyHEADmaster
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] Change-Id: I7520c2b314f271b16bcc07821fd7e3cc3c98591b Task-number: QTWEBSITE-862 Reviewed-by: Lars Knoll <>
1 files changed, 90 insertions, 0 deletions
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
+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 tracker,
+but should instead be sent to
+What Happens When an Issue is Reported?
+* Email sent to 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 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
+* 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
+ mailing list.
+* All members of the 'core security' team must have posting rights for the
+ 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.