tl;dr: A new sec-approval flag on patches, used for sec-high and sec-critical rated security issues. Need approval to check those in as of 9/30/2012.
We, the Security Assurance and Release Management teams, have created a new flag for patches, 'sec-approval', which has '?', '+', and '-' states. This flag is live in Bugzilla right now. As discussed a number of times over the last few months, we're trying to avoid the situation where we check in security sensitive fixes and wind up creating unacceptable risk for our users through early exposure. Obviously, there is a trade off here since we have to check in fixes at some point but the idea is to limit the exposure of especially sensitive (and severe) bugs. *This flag and process only applies to sec-high and sec-critical bugs as outlined below.* With the new flag in place, we're implementing this policy as mandatory for security bugs as of the end of the month (September 30, 2012). Since there are no enforcement hooks in place within hg, this is effectively being done on the honor system by developers but we do review all security fixes. I expect that it will take people a while to get used to this and that people may initially forget to follow the process. The process is actually pretty simple and won't affect most developers, since the group of people writing security related fixes is fairly small. The process is as follows: 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 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 and have a beer! 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. If there are any questions or discussions, please reply here or send e-mail to me, Dan Veditz, and/or Alex Keybl. -- Curtis Koenig Program Manager Mozilla Security Team _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
