Frank Hecker wrote:
> However I'll have to defer to our Bugzilla experts on the question of
> how many Netscape confidential bugs remain in the public Bugzilla
> database, and how soon they could be removed.
BTW: Re timing: With "fast" I meant more days than weeks :).
> those who are responsible
> for Mozilla distributions and other Mozilla-based products
> criteria: whether the Mozilla distribution or Mozilla-based product is
> generally available for public use or not, how big of a user base it
> has, how known and trusted within the Mozilla community are the people
> behind the distribution, and so on.
These criteria are inherently troublesome, even questionable.
But I have no better suggestion. I guess, it depends a lot on the
weigthening - e.g. what you consider "large" and how you weigth the
different critera against each other.
> And in principle this problem is no worse than the problem of
> selecting who gets CVS write access and who doesn't.
It is, because you can submit patches without CVS write access. It is
just less fun, technically inferior and a bit less convient.
In this case, pleople are potentially cutted from information they need
to do their business.
But again: I have no good solution either.
> I think the core security group (the people responsible for coordinating
> investigation and resolution) shouldn't be more three to five people at
> most; in my opinion the group doesn't need to be any larger than that in
> order to be effective. (The core group can always invite more people to
> get involved for a particular bug, as described above.)
Oh, that's very small, too small IMO. With brendan, shaver, mstoltz and
jar (sorry, if I forgot someone), you'd have your group complete already.
I think, there are more people who are interested in security bugs and
also trustworthy. If they match both criteria, it is IMO a good thing to
add them to the group - they add more reliability, and they can add
their input or contribute fixes to *any* security bug.
Let's say, I'd make it my goal to make Mozilla more secure. I'd not only
hunt for new bugs and fix them, but would like to be able to see and fix
other known security bugs. Maybe I make it my goal to fix the security
bugs I "like" within 2 hours after reporting, assuming I am reachable.
With your proposal, I couldn't.
I don't think, this is an unreasonable or uncommon scenario, i.e. I hope
there will be more than 3 of those people in the long run, not counting
those who /occasonally/ provide fixes or input for random security bugs.
> The second group (people invited by the core group to help with a
> particular problem) could be significantly larger, say 10-30 people.
Since many people work on a volunteer basis, I'd make like to make
"invitation" to contribute fixes more the exception than the regular
process.
I imagined it like that: If a bug is found in a particular area, the
person causing the bug, the module owner and a few other relevant
people, assuming trust, are cced. The first person who claims the bug
assignes it to him-/herself. Usually, the person who caused the bug will
be interested in fixing it him-/herself. Or the other "area specialists"
or the frist security group could jump in, whoever is faster. Others
review / provide input.
> Note that IMO the people on this "Mozilla
> distributor" list could and should include representatives from
> "non-corporate" projects like Galeon and K-Meleon, not just
> representatives from "corporate" projects like Netscape 6
Sure.
But I think, that group would be easiest to get into, so it would impose
the largest risk.
> "business days", say 5 business days.
Note that holidays are different all over the world.
> The purpose of this
> initial period is to assess the severity of the problem, put in place a
> plan to address it, and write up information for public release;
IMO *this* should be a matter of hours.
> I don't think a one or two day period before automatic disclosure is
> long enough to do that in all cases: people might not be immediately
> available, the initial characterization of the problem might be
> incorrect or incomplete, etc. That's why I think a somewhat longer
> period is better.
I think, the period should be enough to fix the problem in most cases.
That's the rationale behind the temporay hiding - being able to fix the
problem before any cracker has a chance to exploit it (ideally) - not?
> I guess the idea is that if the initial
> reporter of the new bug explicitly marked "I want full disclosure" then
> no one else would be able to "hide" the bug.
That's OK, for the reasons you gave in your initial post, not?
(You cannot "unconfirm" a bug either.)
> I'm not sure exactly what you mean by "start with proposals for
> details".
You're heading in the right direction. I just wanted us to get concrete
now, since we seem to have, IIRC, mostly consensus on your
"meta-proposal", and it is about time to implement it.
