I don't think this policy should directly affect your pushes to try server. The goal of the policy is to prevent us from landing security patches on mozilla-central at inconvenient times.
But, it does raise a separate point that we might need to discuss further: pushing security patches (and tests) to try has many of the same security implications that pushing them to to the main repositories does (with slightly different visibility characteristics). Developers working on security bugs need to be wary of that, and need to know that they should take appropriate precautions (e.g. don't list the bug #, don't include comments, use an innocuous summary, etc.). Gavin On Wed, Aug 22, 2012 at 3:23 PM, Justin Lebar <[email protected]> wrote: > It seems like I can't push my security bug to tryserver until after I > get approval, since that would have the same problem as landing on > m-c. > > That would make life pretty difficult, since I'd need to write the > patch, get a review, wait a week for approval, land on try, and only > then discover that my patch breaks something. > > Three similar sg-high's I've dealt with which have needed tryserver > coverage are bug 775009, bug 757376, and bug 687745. (For those not > in the security group, these are all docshell bugs, one of which is > currently un-resolved.) I don't deal regularly with security bugs, so > I don't know whether I'm an edge case here. > > -Justin > > On Wed, Aug 22, 2012 at 11:32 AM, Al Billings <[email protected]> wrote: >> 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-planning mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-planning > _______________________________________________ > dev-planning mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-planning _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
