I will point out that the references to "me" below are references to me, Al Billings, not Curtis, who re-posted this older announcement while I was trapped in Maine for a week.
Al On 10/18/12 11:08 AM, Curtis Koenig wrote: > 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 > > > _______________________________________________ > Security-group mailing list > https://mail.mozilla.org/listinfo/security-group -- Program Manager Mozilla Security Team _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
