> Frank Hecker wrote: > > If you have comments or questions concerning it, please post them > to this newsgroup/mailing list, and I'll try to address them as best I > can.
Just a couple... > The mozilla.org Bugzilla system is > being modified to remove the ability to mark bugs as "Netscape > Confidential," and to instead implement the scheme described below. Yay! :) > At the same time the Mozilla project receives substantial > contributions of code and developer time from organizations that use > (or plan to use) Mozilla code in their own product offerings. Some of > these products may be used by large populations of end users, many of > whom may not often upgrade or check for recent security fixes. We > understand and acknowledge the concerns of those who believe that > too-hasty disclosure of exploit details can provide a short-term > advantage to potential attackers, who can exploit a problem before > most end users become aware of its existence. 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. 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. > * As noted above, information about security bugs can be held > confidential for some period of time; there is no pre-determined > limit on how long that time period might be. However this is > offset by the fact that the person reporting a bug has visibility > into the activities (if any) being taken to address the bug, has > the primary responsibility for deciding when the bug report > should be opened for public scrutiny, and has the power to do so. 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. This gives a minimum of <m> full milestone periods to fix the bug after its security implications are understood, and <n> weeks for all vendors to perform a release based on that milestone. With suitably chosen m and n, there would be no legitimate reason not to disclose by that point. > 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? (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). Stuart.
