|
|
| (17 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| For security bugs with no sec- severity rating assume the worst and follow the rules for sec-critical. If you have experience fixing security bugs you could also take a crack at rating it yourself following the [[Security_Severity_Ratings]]
| | = MOVED = |
| | | = This page moved to [https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html Firefox Source Docs: Security Bug Approval Process] = |
| 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.<br>'''OR'''
| |
| # The bug is a recent regression on mozilla-central (this means that the specific regressing check-in has been identified 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.
| |
| | |
| 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:
| |
| #request sec-approval (to be safe) and wait for a rating, <br>or
| |
| # rate it following the 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!
| |
| | |
| An automatic nomination comment will be added to bugzilla when
| |
| sec-approval is set to '?'. The questions in this need to be filled out
| |
| as best as possible when sec-approval is requested for the patch.
| |
| | |
| 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?
| |
| | |
| This is similar to ESR approval nomination form and is meant to help us
| |
| evaluate the risks around approving the patch for checkin.
| |
| | |
| When the bug is approved for landing, the sec-approval flag will be set
| |
| to '+' with a comment from the approver to land the patch. At that
| |
| point, land it.
| |
| | |
| This will allow us to control when we can land security bugs without
| |
| exposing them too early and to make sure they get landed on the various
| |
| branches.
| |
| | |
| The security assurance team and release management will have their own
| |
| process for approving bugs:
| |
| | |
| # The Security assurance team goes through sec-approval ? bugs daily and approves low risk fixes for central (if early in cycle). Developers can also ping the Security Assurance Team (specifically Al Billings & Dan Veditz) in #security on IRC when important.
| |
| # 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.)
| |
| # 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.
| |