[Development] RFC: Qt Security Policy

[Giuseppe D'Angelo]

Hi Richard,

many thanks for the insightful mail.

On 8 October 2012 22:49, Richard Moore <rich at kde.org> wrote:

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

This requires advertising such address properly, on the main
qt-project website, on the wiki, etc.

Unfortunately, from that point of view (website, etc.) there's still a
long list of things to be done. It would be a shame if putting the
address there becomes another bullet in a TODO list...  If it's
quickier and more effective, I would recommend (also) accepting
submissions in JIRA -- provided that submissions targetting security
issues are automatically made non-visible by people outside the
security team, and that an automatic mail is sent on the
security-internal ML.

> == What Happens When an Issue is Reported? ==
>
>  * security@ should be sent to a 'core security' team of developers who need
>    not be maintainers.

Maintainers in the meaning of the Qt governance model? If so, I think
you meant Approvers here. In other words: I'd like to have any
community member in the security team, if it makes sense for them to
stay there.

>  * Any issue determined to be high risk should be immediately reported to the
>    Chief Maintainer.

Nitpicking, do you mean here by the security team or by the original reporter?

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

Seems reasonable to me, although this point has actually a broader
scope than security and should be probably discussed in another
thread.

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

In order to handle these last points, were you thinking about having a
dedicated mail address for which no mails are accepted, and it's used
only for posting security announcements on announce@? (It could
automatically bounce mails with something like "please discuss on the
development ML"),

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

I would just post messages coming to that address to the security-internal ML...

>  * Should there be a security maintainer role?

It fits perfectly with the role of a Maintainer (esp. the "orthogonal"
ones, who are not tied to a particular piece of code but rather ensure
the quality of a particular aspect all over Qt), so why not? Of course
you have to find someone willing to step up first ;-)

Thanks,
-- 
Giuseppe D'Angelo