Stuart Ballard wrote: > Can we make it formal policy that a bug which *did not exist* in any > previous milestone can never be "security-sensitive"? That is, if a bug > is reported between 0.9.7 and 0.9.8, and it turns out that 0.9.7 is not > affected by this bug, then the bug should be kept public. > > My logic is that in this situation, no (reputable) distributor will ever > have made a release containing the bug, so the legitimate argument for > confidentiality disappears.
Interesting point. This is certainly something that I would expect the security module owner, peers, and the rest of the security bug group to take into account. Whether it should be part of the overall policy or not is a good question. (I agree that a distributor wouldn't typically use a non-milestone release as a base, but I can't necessarily absolutely rule it out.) > To go one step further, if all "vendor representatives" in the security > group confirm that the vendor they are associated with has not made a > release containing this exploit, it should again be disclosed > immediately. Same point as above: I can definitely see including this as part of mozilla.org guidance to the module owner, peers, and the security bug group, but I'll have to think a little more about whether it should be part of the formal policy. If you're wondering why I'm reluctant to commit on this, I have the selfish motivation that I don't want mozilla.org staff (including me) to have to specify in advance excactly what should be done for each and every possible contingency. I would prefer to delegate to the module owner, peers, and the security bug group where possible. > I agree with Ben that there should be a pre-determined time limit on > this, enforced by Bugzilla. Something like "<n> weeks after the <m+1>th > milestone release after the bug was first marked security sensitive" > would be good, where m and n are appropriately selected. Perhaps if the > bug is first marked security sensitive in a freeze period, the counter > would start at the next milestone. I sense complications creeping in :-) To repeat, I'm not confident in our ability to pick (especially in advance) a single time limit scheme that everyone is happy with and that will make sense in every possible combination of circumstances. However I'm happy to have experience to prove me wrong, and if we adopt an initial policy without fixed time limits, I'd be glad to go back and revisit the question later. >>The original reporter of a security bug has the primary responsibility >>for deciding when that bug will be made public; disclosure is done by >>clearing the bug's "Security-Sensitive" flag, after which the bug will >>revert to being an ordinary bug. We believe that investing this power >>and responsibility in the bug reporter simply acknowledges reality: >>Nothing prevents the person reporting a security bug from publicizing >>information about the bug by posting it to channels outside the >>context of the Mozilla project. >> > > Note that this is also true of everyone in the security group and > everyone cc'd on the bug. In the same spirit of "acknowledging reality", > shouldn't those people also be able to unset the flag? That's a good point, and one I don't have a firm opinion on just yet. It's certainly my opinion that _someone_ other than the bug reporter be able to unset the flag, to allow for overriding the bug reporter in extraordinary cases. But I can also see for restricting this power somewhat. For example, it might be the case that someone in the security bug group gets in a personal argument with the bug reporter about disclosure; I don't necessarily want to allow a random security bug group member to be able to easily unset the security-sensitive flag in a temporary moment of irritation. (Of course the bug reporter could get irritated too and unset flag in a fit of pique, but arguably the bug reporter would have a greater right to do so than a random security bug member would, since they reported the bug in the first place.) > (Of course, people in the security group can be expected to comply with > mozilla.org policy, but others added to the cc: list might not, no > matter how carefully they are selected by those working on the bug). Right, so if we did expand the technical power to unset the "security-sensitive" flag and allow all security bug group members to do so, I'd prefer to not extend that power to people who were merely added to the bug's cc list. Frank -- Frank Hecker [EMAIL PROTECTED]
