Security/Bug Approval Process: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 26: Line 26:
It is as follows (courtesy of Dan Veditz):
It is as follows (courtesy of Dan Veditz):


[Security approval request comment]
: [Security approval request comment]
How easily can the security issue be deduced from the patch?
: How easily can the security issue be deduced from the patch?
 
:
Do comments in the patch, the check-in comment, or tests included
: Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
in the patch paint a bulls-eye on the security problem?
:
 
: Which older supported branches are affected by this flaw?
Which older supported branches are affected by this flaw?
:
 
: If not all supported branches, which bug introduced the 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?
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?
 
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
This is similar to ESR approval nomination form and is meant to help us
Line 56: Line 53:
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.
# 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.)
# 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.
# 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.
canmove, Confirmed users
4,854

edits

Navigation menu