Handling security issues

[Simon Green]

Hi guys,

In last months meeting[1], we discussed having a more formal policy on
how to handle security issues. This came about in part due to the time
it took for bug 1036213 to go live, despite the fact that the exploit
was mentioned on social media and slashdot hours before the bug was filed.

Here is my suggestions:
* All security bugs to be triaged one business day by a APL or PL. This
should determine if the issue is valid, and the severity. (the sec-low,
sec-moderate and sec-high keywords can be used for this)

* A high security bug would include (but is not limited to) data leakage
(including CSRF / XSS attacks) or when the exploit is made publicly
available (as was the case with bug 1036213). This would also include
non-security bugs that could cause data corruption. In these case, a new
point release should be done ASAP.

* A medium security bug would include things such as bug
1054702 and bug 873932[2]. They should be fixed ASAP, but be in the next
scheduled release.

* Low security bugs (for example bug 761043 and 301686[2]) should be
fixed as developer time permits, and be in the next schedule release

* This guide applies mainly for bugs from now onward. The existing 14
security issues can be dealt with as time permits.

-- 
Simon Green
Software Engineer
Red Hat Asia Pacific Pty Ltd

[1] https://wiki.mozilla.org/Bugzilla:Meetings:2014-06-25
[2] Sorry to the people that can't see these bugs.