Frank Hecker wrote: > > 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 started writing a response to this and ended up making the same points in about three places, so I'll amalgamate them all. Sorry about the length of this... :) First off, I have to say I'm really impressed with this policy in general and grateful for the amount of work that's gone into it. I'd be content (with a little grumbling :) ) to see it stand "as is". My only concern is the way it seems to "default" to closed status, which is more a matter of emphasis than anything else. My two points about eventual disclosure being mandatory and keeping bugs that don't apply to any milestone open were both in reaction to this same issue, and having thought about it some more, I agree that hard and fast restrictions aren't the way to go. What I would like to see though is something explicitly in the policy stating that closing a bug requires some justification, and that absent such justification, openness is the default. Make it vague and waffly and leave final discretion to the security group on a case-by-case basis, but make it clear that the *intent* is that bugs should be kept open unless there are reasons not to, and should be opened afterwards as soon as the reasons no longer apply. Right now the policy seems to suggest an "it's a security bug, so set the flag" attitude. I'd like to see something that says that "it's a security bug" is not sufficient by itself to justify having this flag - there must be some further reason. It may be that someone's latest branded release has the bug, or something else, but there must be *something*. And when that "something" no longer applies, the bug should be opened; the current policy leaves it up to the reporter with the implication that overriding by the module owner or staff@mozilla will be a rare last resort. I'd like it to be more clear that the module owner and the security group will routinely work to open up a bug - preferably with the consent of the reporter, but without the reporter having to initiate the process. Just suggest that the security group be actively looking for the earliest time consensus on opening the bug could be reached, as opposed to passively waiting until the reporter suggests it. > 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. <snip> > ... I'd prefer to not extend that power to people who were merely added > to the bug's cc list. My point is that they have that ability simply as a result of being able to view the page: file -> save page, and then send the html to n.p.m.general. This ability cannot be taken away as long as the person has access to the bug. Presumably the security-sensitive flag could be set back again after the moment of irritation had passed, while it might be a lot harder to get back information that had been posted to a public newsgroup. Thus the ability to unset the flag is a much *smaller* privilege than what they have already just by virtue of seeing the page. Again, I'm very impressed with the policy in general - all my concerns are really matters of emphasis rather than with the hard-and-fast rules, which I agree with. Thanks for taking the time to work on this, and to answer my concerns. Stuart.
