[Development] RFC: Qt Security Policy
rich at kde.org
Mon Oct 8 23:49:55 CEST 2012
I'm including the text inline since I've had a request for that.
= Current State =
== How did we do during the recent CRIME attack? ==
* We provided a fix.
* security at qt-project.org was shown to be non-functional (no reply, no
* We were initially unable to send an email to announce at qt-project.org.
* Once sent, the email gave the impression this was a digia fix which was
unfair to people like KDAB etc. since digia were only involved in sending
the notification, rather than understanding or addressing the issue.
* The from address of the advisory etc. means that people who have genuine
questions about the fix cannot contact the relevant people.
* It was unclear which versions of Qt should get security fixes - where is
our lifecycle defined? I ended up providing fixes for 5.0, 4.8 and 4.7.
* Previously we notified people via a blog, that did not occur this time, we
need to be consistent.
=== Lessons Learned ===
* The security@ email address needs to be completely reworked.
* The process for releasing advisories needs to be defined and processes put
in place to allow it to be executed.
* The support lifecycle of Qt releases needs to be defined.
= Proposed Security Policy =
== Reporting Security Issues ==
* Security issues should not be reported via the normal
bugreports.qt-project.org tracker, but should instead be sent to
security at qt-project.org.
== What Happens When an Issue is Reported? ==
* security@ should be sent to a 'core security' team of developers who need
not be maintainers.
* The 'core security' team should start by determining if an issue falls
within the purview of an existing maintainer, if so then they should inform
* Whilst maintainers are responsible for addressing any security issues in
the code they maintain, the 'core security' team are responsible for
ensuring that the issue is addressed, and that the security policy is
* The 'core security' team are not responsible for fixing issues, merely for
managing the process.
* Any issue reported to security@ should receive (at least) an
acknowledgement of reciept 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 at qt-project.org.
* If there is no response in the above time frame, then you should contact
the chief maintainer directly (this should never happen).
* Any issue determined to be high risk should be immediately reported to the
== What Version of Qt are Supported? ==
* Fixes are only guaranteed to be provided for:
* The latest released version version (currently 4.8).
* The preceding minor version (currently 4.7).
* Fixes for earlier versions may be provided, but the qt-project makes no
comitment to do so. Other groups such as Digia 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 annouce at
* All members of the 'core security' team should having posting rights the
annouce at qt-project.org list for this purpose.
* All security annoucements will be made on behalf of the Qt Project, though
credit to those responsible for identifying and addressing the issue should
* The security annoucement 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 annoucement 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 annoucements,
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 be
considered priviledged information. A security-annouce list for
distribution contacts will be used for this purpose.
* Membership of the security-annouce 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 explanation required.
* Where possible packagers should be informed directly of which SHA1s they
should cherry pick in order to get a security fix.
== Problems / Actions ==
* A 'core security' team needs to be formed.
* security at qt-project.org email should be directed to the members of the
'core security' team. Steps in this direction have already been made, the
security at qt-project.org list has been updated.
* The members of the 'core security' team need to be granted posting rights
to the annouce mailing list.
* Create a private security-announce mailing list.
* Reach out to packagers who should be added to the list.
* Should there be a security maintainer role?
More information about the Development