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

m
Adding "Testcases" to heading of the "landing" section
m (→‎VulnSmash: format fix done right this time)
m (Adding "Testcases" to heading of the "landing" section)
Line 85: Line 85:




== Landing Fixes ==
== Landing Fixes and Testcases ==


External parties watch check-ins in order to identify security patches [https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome/][https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html], and we have both documented and suspected cases of this for Firefox patches. 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.
External parties watch check-ins in order to identify security patches [https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome/][https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html], and we have both documented and suspected cases of this for Firefox patches. 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.
canmove, Confirmed users
637

edits