[Development] RFC: Qt Security Policy

[Knoll Lars]

Hi Rich,

thanks for putting this together. I like the proposal. It's lightweight, but will IMO cover our needs.

On Oct 9, 2012, at 1:07 AM, Giuseppe D'Angelo <dangelog at gmail.com> wrote:

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

This can be done, but would require some work in Jira (I'm unsure how much). Matias, any idea?

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

In principle that's true. But any developer with sufficient experience and trust from the community will most likely be an Approver anyway.
> 
>> * 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?

I'll be on the security mailing list anyway ;-)
> 
>> == 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.

I think there might be an exception now with Qt 4 vs Qt 5, as we'll most likely need to support 4.8 (and maybe even 4.7) for quite some time to come (ie. even after 5.1/2 is out).
> 
>> == 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.

The announcements should be as much as possible self explaining. But we might miss some things in it. So it might actually make sense to actually keep the details on the wiki, so that we can amend and update the description if we see that there's further need for clarification.
> 
> 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 ;-)

I'd be in favour of having that role. The main reason is to have someone who makes sure we process issues according to the guarantees we are giving in our security policy.

Cheers,
Lars