Stuart Ballard wrote: >It may be that someone's latest >branded release has the bug, or something else, but there must be >*something*. > That's almost always the case. The worst and thus most important and interesting bugs will probably be kept condfidental for a years or so.
>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. > I don't think that will work. I expect many parties with an interest in closure being members of the security group, and people falling back to closed when they are not sure, because "there's nothing to harm if we don't disclose, but much to harm if we do" (they think). In other words, I trust neither mozilla.org staff nor the security group at large to do the right decisions about disclosure. Even if they do the right thing most of the time, that's not enough. It's the exceptions that count here. One open security hole is enough to let everything fall.
