Mitchell Stoltz wrote:
As module owner, I'd be happy to maintain that page, along with
whoever we pick as peers. As with the rest of this proposal, I expect
that the amount of information disclosed on the public page will be
decided by consensus among the security group on a per-bug basis.
Consensus is such a thing. Do we have consensus on a security policy
for Mozilla? No.
! pWhen a bug is put into the security group, the security
! group members, bug reporter, and others associated with the bug
! will decide, either through comments on the bug or the security group
! mailing list, whether an immediate warning to users is appropriate
! and how it should be worded. This warning should mention the existence
! of a vulnerability, which features or modules are affected, and a
! workaround, if one exists. The module owner, a peer, or some other
! person they may designate will post this message to a
! Known Vulnerabilities page, which will be maintained at a well-known
! location on on www.mozilla.org. These messages will contain all of the
! information that the security group has agreed to be safe for
! immediate public disclosure. Mozilla distributors who wish to inform
! their users of the existence of a vulnerability may repost these
! messages to their own websites, mailing lists, release notes, etc, as
! long as they don't disclose any additional details about the bug./p
That's much less than you said were OK in your last posts and much less
than I need. You now constrain the info I give my users to what you
publish for Mozillam, while yesterday, you said You can inform *your*
users via your mailing list, release notes, etc, as long as you make an
effort not to provide enough information to allow someone to reproduce
the bug.
I want to issue warnings (to my users)
1. for *all* bugs I consider severe enough and
2. in I wording I choose, with content I choose (as long as I don't
disclose reproduction info or something close to it)
Rationale:
2., because my users are of course less technically savvy than Mozilla
contributors, and the workarounds are also likely to be different for
Beonex Communicator (different default settings, different install
strategy etc.). I might even need to reveal more (still vage) facts
about a bug than the official warning does, when I think that this is
necessary for my users to judge their risk and to work around the bug.
Reaching consensus also takes time, more time than is acceptable for
me in some situations.
1.: please try to understand my situation. I see a bug, know that users
risk their whole network security because of that buffer overflow, and,
for any reason, the reporter or the security group decides not to issue
a warning, so I am not allowed to warn my users. That's unacceptable and
cruel (sorry for the hard word, but that's how I feel about it).
If you want to prepare the warnings for mozilla.org, incl. their
wording, in the security group, that's certainly fine with me.
BTW: I wouldn't define a web-page, because I think that
newsgroups/mailing lists are the best method to publish such urgent and
important info. Having the same info additionally on a webpage is surely
nice, though.
pIf disputes arise about whether or when to disclose information
! about a security bug, the security group will discuss the issue via
! its mailing list and attempt to reach consensus. If
necessary mozilla.org staff will serve as the court of last
resort./p
Great!