Qt Project Security Policy

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 sent to a 'core security' team of developers who may or may not be maintainers.

• The 'core security' team 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@qt-project.org 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@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 by the security team.

What Version 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 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@qt-project.org mailing list.

• All members of the 'core security' team should having posting rights the annouce@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 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 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 be considered privileged 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 no explanation required.

• Where possible packagers should be informed directly of which SHA1s they should cherry pick in order to get a security fix.