|
|
| (21 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| Core-security bug fixes should just be landed by a developer without any
| | = MOVED = |
| explicit approval if:
| | = This page moved to [https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html Firefox Source Docs: Security Bug Approval Process] = |
| | |
| # The bug has a sec-low, sec-moderate, sec-other, or sec-want rating.
| |
| *#OR*
| |
| # 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.
| |
| | |
| 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:
| |
| a) request sec-approval (to be safe) and wait for a rating, or
| |
| | |
| b) 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!
| |
| | |
| 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:
| |
| | |
| 1. The Security assurance team (specifically me and 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.
| |
| | |
| 2. 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.)
| |
| | |
| 3. 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.
| |