Security/Firefox/Security Bug Life Cycle: Difference between revisions

Security/Firefox/Security Bug Life Cycle (view source)

Revision as of 20:30, 1 October 2019

1,102 bytes added , 1 October 2019

added bit about in-testsuite flags

Dveditz

canmove, Confirmed users

637

edits

@@ Line 1: / Line 1: @@
-Security bugs in our product put millions of people at risk. To fulfill Mozilla's mission we must discover those bugs, fix them, and ship the fixes. This process involves multiple teams across the organization. This page describes a bug-centric view of the tasks that are part of that process, serving almost as a checklist to make sure we are executing on each step. There are also handy bugzilla queries that will be helpful for engineers as they work on each task.
+Security bugs in our product put millions of people at risk. To fulfill Mozilla's mission we must discover those bugs, fix them, and ship the fixes. This process involves multiple teams across the organization. This page describes a bug-centric view of the tasks that are part of that process, serving almost as a checklist to make sure we are executing on each step. There are also handy bugzilla queries that will be helpful for people as they work on each task.
@@ Line 5: / Line 5: @@
-'''Note:''' The bugzilla links in this document are intended for engineers performing the tasks described in the sections where they are found. Most of them will yield empty or incomplete results unless you are logged in to bugzilla.mozilla.org and have access to security bugs.
+'''Note:''' The bugzilla links in this document are intended for the people performing the tasks described in the sections where they are found. Most of them will yield empty or incomplete results unless you are logged in to bugzilla.mozilla.org and have access to security bugs.
 = A Bug is Born =
@@ Line 86: / Line 86: @@
 External parties watch our check-ins in order to identify security patches; we have several documented cases of this. We don’t want to 0-day ourselves by landing obvious fixes that sit in the tree for a long time before they are shipped in an update, and we especially don't want to land test cases that demonstrate how to trigger the vulnerability. The [https://wiki.mozilla.org/Security/Bug_Approval_Process '''Security Bug Approval Process'''] is designed to prevent that. Part of the approval process is evaluating what bugs need to be pushed to Beta and which are risky and need to ride the trains, and whether or not the patch is needed on supported ESR branches.
+Testcases for vulnerability fixes should be split into a separate patch for this "sec-approval" process. These testcases should land ''after'' we have shipped the fix in Release, usually by a few weeks to give users time to have applied the update. We '''must''' track the task of landing these patches later. You have two main options, and either are fine:
+# Create a task bug assigned to yourself ("Land tests for bug XXXX"). It must be a hidden security bug like the main vulnerability was. Add the keyword '''sec-other''', or
+# Track it in the original bug using the '''in-testsuite?''' flag. If you go this route you must remember to check for un-landed tests (queries below). Once the tests are landed change the flag to '''in-testsuite+'''.
 [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20sec-approval%3F '''Pending sec-approval requests''']
+[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20flag%3Ain-testsuite%3F%20kw%3Asec-%20assignee%3A%25user%25 '''"My" security bug testcases that need landing''']
+[https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20flag%3Ain-testsuite%3F%20kw%3Asec-&limit=0&order=cf_last_resolved '''All unlanded testcases for fixed security bugs''']