Hi, This is a proposal for approving checkins for security bugs that was previously discussed in the security-group within Mozilla. This has been discussed a bit with release management and those of us who do security bug triage (and approval of checkins) a bit. I wanted to circulate this winder to dev-planning and dev-security now.
The overall goal of this process is to avoid accidental disclosure of security issues through checkins and to make it very easy for developers to know when they are clear to go ahead and check in a security fix. The proposal below is likely to become the plan of record unless significant objections are made to it. We've had enough issues and questions raised in the last few months that the need for a change has become pretty clear to those of us working with this day in and day out. Please reply with concerns and feedback, either to me or to the group(s). Al ----- This is a revisit of the Security Bug Approval proposal from early June. Having spoken to Alex about this a bit, he has been wanting to get this in place and I think the security assurance team is in agreement on this as well. We've had a number of close calls and potential exposures during the past few release cycles. We have had a problem in people knowing when they should land high impact or serious security issues on Mozilla Central. There are concerns that landing at the wrong time exposes us to a risk of a Zero Day or similar problems. Developers have said that they both (a) don't want a lot more process but also (b) need to know when it is fine to land a security fix without serious risk. We have a draft proposal and some action items to try to address the lack of clarity for security bug landing. We explicitly wanted to set up a process that was lightweight for developers. This should be low overhead, just as is landing fixes on ESR. This process only applies to core-security bugs and not web related bugs or public (non-hidden) bugs. *Proposal* The proposal is that we create a new flag, 'sec-approval', which will have ?, +, and - states. This flag will apply to higher severity security bugs ONLY. 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. Otherwise, if the bug has a patch *and* is sec-high or sec-critical, the developer should set the sec-approval flag to '?'. If the bug is a hidden core-security bug with no rating then either: a) request sec-approval and wait for a rating, or b) rate it and then proceed according to whether the bug is low/moderate or high/critical 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 '?' and this will ask: a. How obvious is this problem (from reading through the patch)? Can it be deduced by a third party from it? b. How risky is the fix? c. What versions of Firefox are affected and to which does the patch apply cleanly? d. A link to wiki page with details of this process for clarity for developers. This is similar to ESR approval nomination form. 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, developers can land the patch. This is done on the honor system. There will be no programmatic enforcement of needing the sec-approval flag set to '+' to land. 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. Security assurance team 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.) 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. Please send further thoughts, comments, or concerns about this for discussion. Al -- Program Manager Mozilla Security Team _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
