Security/Bug Approval Process

Purpose: don't 0-day ourselves

People watch our check-ins. If the patch is an obvious security fix, the check-in comment says "security fix", or the testcase shows how to trigger a vulnerability someone may be able to start exploiting our users before we were planning to ship that fix.

Principle: assume the worst

• If there's no rating we assume it could be critical
• If we don't know the regression range we assume it needs porting to all supported branches

Process

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

Core-security bug fixes should just be landed by a developer without any explicit approval if:

1. The bug has a sec-low, sec-moderate, sec-other, or sec-want rating.
   OR
2. 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:

1. request sec-approval (to be safe) and wait for a rating,
   OR
2. rate it following the Security_Severity_Ratings 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 the 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 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.
2. if the requestee or others have identified the regressing bug, add "regression" keyword and put the bug in the "blocks" field.
3. 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.)
4. 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.