canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Bug Approval Process: Difference between revisions
no edit summary
(Created page with "Core-security bug fixes should just be landed by a developer without any explicit approval if: # The bug has a sec-low, sec-moderate, sec-other, or sec-want rating. *#OR* # The ...") |
No edit summary |
||
| Line 1: | Line 1: | ||
===sec-low, sec-moderate, sec-other or sec-want=== | |||
Core-security bug fixes should just be landed by a developer without any | Core-security bug fixes should just be landed by a developer without any | ||
explicit approval if: | explicit approval if: | ||
# The bug has a sec-low, sec-moderate, sec-other, or sec-want rating. | # The bug has a sec-low, sec-moderate, sec-other, or sec-want rating.<br>'''OR''' | ||
# The bug is a recent regression on mozilla-central. | # The bug is a recent regression on mozilla-central. | ||
This means that the developer can mark the status flags for ESR, Beta, and Aurora as "unaffected." | |||
It also means that we haven't shipped anywhere public in an official release yet. | |||
If it meets the above criteria, check that patch in. | If it meets the above criteria, check that patch in. | ||
===sec-high or sec-critical=== | |||
Otherwise, if the bug has a patch *and* is sec-high or sec-critical, the developer should set the sec-approval flag to '?' on the patch when it is ready to be checked into mozilla-central (or elsewhere if it is branch only). | Otherwise, if the bug has a patch *and* is sec-high or sec-critical, the developer should set the sec-approval flag to '?' on the patch when it is ready to be checked into mozilla-central (or elsewhere if it is branch only). | ||
If you have a patch and the bug is a hidden core-security bug with no rating then either: | If you have a patch and the bug is a hidden core-security bug with no rating then either: | ||
#request sec-approval (to be safe) and wait for a rating, <br>or | |||
# rate it and then proceed according to whether the bug is low/moderate or high/critical as above. | |||
If developers are unsure about a bug and it has a patch ready, just mark | |||
the sec-approval flag to '?' and move on. Don't overthink it! | |||
If developers are unsure about a bug and it has a patch ready, just mark | |||
the sec-approval flag to '?' and move on. Don't overthink it! | |||
An automatic nomination comment will be added to bugzilla when | An automatic nomination comment will be added to bugzilla when | ||
| Line 26: | Line 26: | ||
It is as follows (courtesy of Dan Veditz): | It is as follows (courtesy of Dan Veditz): | ||
[Security approval request comment] | |||
How easily can the security issue be deduced from the patch? | |||
Do comments in the patch, the check-in comment, or tests included | |||
in the patch paint a bulls-eye on the security problem? | |||
Which older supported branches are affected by this flaw? | |||
If not all supported branches, which bug introduced the flaw? | |||
Do you have backports for the affected branches? If not, how different, | |||
hard to create, and risky will they be? | |||
How likely is this patch to cause regressions; how much testing does | |||
it need? | it need? | ||
This is similar to ESR approval nomination form and is meant to help us | This is similar to ESR approval nomination form and is meant to help us | ||
| Line 56: | Line 56: | ||
process for approving bugs: | process for approving bugs: | ||
# The Security assurance team (specifically Al Billings & Dan Veditz) goes through sec-approval ? bugs daily and approves low risk fixes for central (if early in cycle). Developers can also ping us in #security on IRC when important. | |||
through sec-approval ? bugs daily and approves low risk fixes for | # Security team marks tracking flags to ? for all affected versions when approved for central. (This allows release management to decide whether to uplift to branches just like always.) | ||
central (if early in cycle). Developers can also ping us in #security on | # Weekly security/release management triage meeting goes through sec-approval + and ? bugs where beta and ESR is affected, ? bugs with higher risk (sec-high and sec-critical), or ? bugs near end of cycle. | ||
IRC when important. | |||
when approved for central. (This allows release management to decide | |||
whether to uplift to branches just like always.) | |||
sec-approval + and ? bugs where beta and ESR is affected, ? bugs with | |||
higher risk (sec-high and sec-critical), or ? bugs near end of cycle. | |||