Handling Mozilla security bugs, version 1.0
Frank Hecker
http://www.mozilla.org/projects/security/security-bugs-policy.html
the 1.0 version of the mozilla.org policy on handling of Mozilla
security bugs. As indicated by the attached diffs, this is the same
document that I posted a week or more ago on n.p.m.security as draft 8;
the only changes were removing the "draft" designation, changing the
date, and changing the URL for the "known vulnerabilities" page to
eliminate the use of mixed case.
Thanks to all of you who commented on the policy while it was being
drafted. Thanks also to all of you who have participated in
investigating and resolving Mozilla security bugs in the past, and
thanks in advance to those of you who may do so in the future. And, last
but not least, thanks to Mitch Stoltz, who's volunteered to take on the
task of module owner in this area.
Frank
--
Frank Hecker
hec...@mozilla.org
Ben Bucksch
more. It is certainly a big improvement over the current scheme, which
didn't work at all. Also many thanks for seriously considering my
complaints about the policy and adjusting it in some places.
Nevertheless, the fact remains that the policy is far from my point of
view on this matter. I'll summarize here, for the record. The main
remaining problems are:
* It is not garanteed that users will be warned about all severe
security bugs. In particular, there are classes of bugs which
Mitch said he would not even want a warning about.
(A "warning" here is a vage, public discription of the bug
(without reproduction info), which allows users to judge their
risk and take counter-measures.)
* It is unclear, how much freedom distributors have while forwarding
mozilla.org's warnings (those that *are* issued) to their users.
* There is no garantee that bugs will be fixed timely. My approach
would have been to force the disclosure of unfixed bugs after a
certain time (e.g. 2 weeks) after reporting, with exceptions, if
it was not realistically possible to fix the bug during that time.
* The time between a bug being fixed and fully disclosed might be
regularily very long (half a year or more).
Although I am not comfortable with the policy, I will participate in the
security bug group, if allowed to, because I have not much to lose* by
doing so and more to gain.
If my time and energy permits, I will try to act as a connection between
the security-conscious people not in the security bug group and the
group and to act as a voice for openness within the group. However, my
time and enery is limited, so please to not rely on me.
I invite everyone seriously interested in security to apply as member in
the security bug group and help fix and evalute the bugs and to make a
case for openness.
Ben
Mitchell Stoltz
Thanks for your input and for agreeing to participate. Believe me
when I say we did take your comments seriously. Let me sum up my
responses to some of your points, for the record.
> * It is not garanteed that users will be warned about all severe
> security bugs. In particular, there are classes of bugs which
> Mitch said he would not even want a warning abou
> (A "warning" here is a vage, public discription of the bug
> (without reproduction info), which allows users to judge their
> risk and take counter-measures.)
I'm afraid we're going to have to agree to disagree on this point for
now. Let's see what happens with the current policy for a few months. If
I'm not getting pressure from Netscape to release less information, then
maybe we can move towards more warnings. No promises though. Loyalty to
our respective organizations aside, I honestly think that releaseing
even a vague warning for every single bug that goes into the security
group, even if there's no workaround, even if the bug isn't exploitable
on its own, is not in the best interests of the vast majority of our
users. That's my story and I'm stickin' to it.
We should at least agree that any disclosure by one distributor or
security group member is the same as disclosure by all. Your earlier
comments support this.
> * It is unclear, how much freedom distributors have while forwarding
> mozilla.org's warnings (those that *are* issued) to their users.
My apologies - I thought that point was clear. You can use the warning
posted to www.mozilla.org/projects/security/known-vulnerabilities.html.
You can change the wording as you see fit, but you can't add any
information. Again, disclosure by one is disclosure by all.
> * There is no garantee that bugs will be fixed timely. My approach
> would have been to force the disclosure of unfixed bugs after a
> certain time (e.g. 2 weeks) after reporting, with exceptions, if
> it was not realistically possible to fix the bug during that time.
There is no guarantee that any bug will be fixed timely, period. Any
fixed time limits are simply not reflective of reality. The beauty of
open source is that you don't have to wait for Netscape to fix a bug -
if that bug is important enough to you, you can fix it yourself or pay
someone to fix it, in two weeks or two hours.
You might as well drop this point because it's completely unrealistic
and we will never agree to it.
> * The time between a bug being fixed and fully disclosed might be
> regularily very long (half a year or more).
As you said to me on the phone, if we set an arbitrary time limit of one
year, someone will come along and say "well, why not six months?" "why
not one month?" It's a slippery slope. A fixed and arbitrary time limit
is simply not necessary. Bugs will be opened to the public in a time
frame that you and I both consider reasonable. As module owner I will
see to that.
> If my time and energy permits, I will try to act as a connection between
> the security-conscious people not in the security bug group and the
> group
Just make sure your 'connection' doesn't violate any confidentiality.
When in doubt, ask the group first or ask that these "security-conscious
people" be added to the group.
> I invite everyone seriously interested in security to apply as member in
> the security bug group and help fix and evalute the bugs
I second that.
-Mitch