OK, now that it is ultra-urgent for me, other means were not effective
and I even finally have access to bnews.mozilla.org, so I could read the
excelltent post you referenced above, I'm going to respond:
Step 1
As you should know, I Beonex Communicator 0.6, an end-user product based
on mozilla0.6, has been released some time ago, and was quite successful
(at least here in Germany). Personally, I care a lot about security, so
this is a big topic for Beonex, too. I am very interested to fix or
hot-fix all major security bugs ASAP (which is, in my book, the same day
or the day after it has been reported).
However, I am blind. I have no idea, which evil bugs are lying around in
the bug database, or even which ones have already been fixed (because
the checkin msgs are usually obscured). In other words, I have no idea,
when I should release version 0.6.1, unless I see that Netscape released
6.01, which would be a bit late, to say the least.
This is not acceptable, not even in the short term.
Other means (emailing appropriate persons) did not help. That's why I
propose to change the meaning of the "nsonly" flag to "security"
*immediately* as a short-term solution. Netscape confidental information
shouldn't be in bugzilla.mozilla.org anyway. If that is too much of a
problem, create a new flag "security", and be sure to move *all*
security bugs over there (no matter, if they contain Netscape
confidental info or not - here, security is more important). Whatever
you do, do it fast please. I don't believe that no severe security bugs
have been found in the last month, i.e. I need to make an update for
Beonex Comm. soon.
If you did that, you can add a few selected people to that group, and
they ciould see all security bugs, and possibly even help fix them (if
time and XXX permits).
This solution can be implemented very quickly, imposes almost no risk
(if Netscape jumps over its "confidental" bandwagon), and doesn't change
much from before, so it shouldn't be controverisal. However, it only
fixes the most-urgent problems, and is by no means a long-term (or even
a middle-term) solution.
Step 2
Since full, immediate disclosure doesn't seem to have much backing, I
have to agree with Frank Hecker, unless otherwise noted.
Frank Hecker wrote:
> 6. There should be some reasonable way for an individual to apply and
> be approved for membership in the "security group". This does not imply
> that such access must always be granted, but rather that the procedures
> for selecting the members of the group should be reasonably fair and
> justifiable.
And the same rules should apply to everybody.
E.g. is hard to justify that an @netscape.com or @beonex.org email
address immediately qualifies for seeing such bugs, while others have to
prove their qualification.
I especially also include the selection of the inital group here.
As for the actual rules, I'd make the group very small (say, 10 or 20
people) or give *all* Mozilla contributors with CVS write access also
access to security bugs. I can see justifications and reasonable rules
for both, but not so much for a group sized between that (e.g. 100).
> 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.
I agree, because this ensures that the (first) non-disclosure isn't used
to hide bugs or support "laziness" (at a corporate level).
I would define "reasonable" as "one week", considering that bugs in
Linux etc. are usually fixed within hours or at least 2 days.
> 2. Consent not to disclose. I thought about specifically asking people
> whether they wanted their reports to be fully disclosed or not. But then
> I figured this would be redundant and unnecessary: If people reporting
> Mozilla security vulnerabilities to mozilla.org want full (or at least
> additional) disclosure, they are of course still free to report the
> vulnerabilities through other channels as well -- for example, to
> Mozilla mailing lists or newsgroups, to Mozilla vendors, to
> organizations such as CERT, to private or public forums dealing with
> security vulnerabilities, to the press, and so on.
If I wanted to fully disclose a bug, I would still prefer to also have
the bug erport open, because that way, the public could also track the
progress of the bug fixing, and possibly jump in and provide feedback
and/or contribute fixes, and wouldn't have to assume that "they are over
it and will do it right", which is not always correct (e.g., sometimes,
security fixes don't fix the problem completely, open other problems
etc.). After all, that is in part the purpose of full disclosure.
So, you would force me to report the problem to an open forum like a
newsgroup *first*, so the bug doesn't get marked confidental in the
first place. This might slow down the process, which is harmful. Adding
a flag "I want full discluse" (you mentioned that this category would be
special anyway), similar to "Initial state NEW / UNCONFIRMED" (which you
can see for new bugs, if you are allowed to confirm bugs), is not much
of a problem is it?
Can we start with proposals for details, so this can proceed further?
