[Development] RFC: Qt Security Policy

[Richard Moore]

I'm including the text inline since I've had a request for that.

Rich.


= 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
   action).

 * 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
   the maintainer.

 * 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
   followed.

 * 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
   Chief Maintainer.

== 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
qt-project.org
   mailing list.

 * 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
   be made.

 * 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
     applications.

 * 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?