Message from discussion
Handling Mozilla security vulnerabilities
From: Frank Hecker <fr...@collab.net>
Subject: Re: Handling Mozilla security vulnerabilities
Date: 2000/10/24
Message-ID: <39F5D938.B930F0D5@collab.net>#1/1
X-Deja-AN: 685349311
Content-Transfer-Encoding: 7bit
References: <39F5C88E.DD709D34@collab.net> <39F5CF4D.F9D20C6A@univ.ox.ac.uk>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: CollabNet, Inc.
Mime-Version: 1.0
Newsgroups: netscape.public.mozilla.security
Gervase Markham wrote:
> Frank, you seem to spend a lot of your time "working" at collab.net
> actually writing words of wisdom and posting them in Mozilla newsgroups
> :-)
Actually, for the record, I wrote this last night but postponed posting
it until today. Also, I'm responding to you right now while I'm on lunch
beak :-)
> If I don't comment on something, assume I agree with it :-)
Same here. I'll forgo commenting on issues where I either agree with you
or I don't care exactly how the issue gets resolved.
> A useful document for discussing things like this is Rain Forest Puppy's
> RFPolicy, a document on how vendor/reporter relations for security
> issues should ideally be handled. It can be found at
> http://www.wiretrip.net/rfp/policy.html .
This is indeed useful; thanks for the reference. I didn't include
details at that level because 1) I felt it was premature; and 2) I don't
care about all the fine details, just the overall principles and the
critical details.
> > 7. There should be full public disclosure of the security
> > vulnerability (and information relating to it maintained by
> > mozilla.org) after some reasonable amount of time, whether or
> > not the vulnerability has actually been resolved by then.
>
> Is this part necessary? Surely the originator of the security issue can
> go public at any time, if they feel that mozilla.org is trying to cover
> things up, or whatever.
Yes, this is true (as I implied elsewhere in my comments). However, what
if the originator doesn't care if the vulnerability gets disclosed to
others, or if they have their own interest in keeping it secret?
IMO leaving disclosure solely up to the originator and the "security
group" does not address the interests of Mozilla users, developers,
vendors, etc., who are not part of the "security group" and who did not
report the vulnerability, but would nonetheless be potentially affected
by it.
> I would replace this with a suggestion that the relevant Bugzilla bugs
> be immediately made public upon public disclosure of the vulnerability.
> This also avoids the problem of defining a "reasonable amount of time."
I think your suggestion is a reasonable supplement to my proposal;
however IMO it is not suitable as a replacement for a hard and fast time
limit.
> > 5. Composition of the "security group". As I mentioned originally,
> > I am talking about a Mozilla-wide group dealing with problems reported
> > to mozilla.org and information maintained by mozilla.org. This is not
> > intended to be a vendor-controlled group.
>
> I think there's a case for the group to include an "overseer" who, while
> not having detailed Mozilla hacking experience, is a neutral third party
> who can make sure nothing dodgy is going on. This is more to calm
> people's fears about the hidden process than anything else. I'm not sure
> who would be appropriate for such a post; ideally, they wouldn't work
> for any company who is doing work on Mozilla.
This is a reasonable suggestion. However note that I personally would
not volunteer to do this; I'm supposed to be working, remember :-)
Frank
--
Frank Hecker work: http://www.collab.net/
fr...@collab.net home: http://www.hecker.org/