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
@@ -0,0 +1,90 @@
+Title: Qt Project Security Policy
+Author: Volker Hilsheimer
+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 email@example.com
+What Happens When an Issue is Reported?
+* Email sent to firstname.lastname@example.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
+* 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 email@example.com 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 firstname.lastname@example.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
+How will Issues be Disclosed?
+* Security issues will be disclosed by an email to the email@example.com
+ mailing list.
+* All members of the 'core security' team must have posting rights for the
+ firstname.lastname@example.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
+* 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.