1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
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.
|
