Left the file extension off the diff file, which garbled it. So, I'm sending it again. -Mitch
*** security-bugs-draft6.html Mon Oct 8 20:00:15 2001 --- security-bugs-draft7.html Mon Oct 8 20:26:16 2001 *************** *** 1,6 **** <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd";> - <html> <head> --- 1,5 ---- *************** *** 20,27 **** <div class=version> Version 1.0<br> ! DRAFT 6<br> ! September 30, 2001 </div> --- 19,26 ---- <div class=version> Version 1.0<br> ! DRAFT 7<br> ! October 8, 2001 </div> *************** *** 194,205 **** have visibility into all Bugzilla data hosted through mozilla.org.)</p> ! <p>The Mozilla security bug group will have a private mailing list to which everyone in the security bug group will be subscribed. This ! list will act as the well-known address to which users can submit ! new security bugs, as well as a forum for discussing group policy ! and the addition of new members, as described below.</p> ! <h3>Other participants</h3> --- 193,209 ---- have visibility into all Bugzilla data hosted through mozilla.org.)</p> ! <p>The Mozilla security bug group will have a private mailing list, ! [EMAIL PROTECTED], to which everyone in the security bug group will be subscribed. This ! list will act as a forum for discussing group policy ! and the addition of new members, as described below. In addition, ! Mozilla.org will maintain a second well-known address, ! [EMAIL PROTECTED], through which people not ! on the security group can submit reports of security bugs. Mail ! sent to this address will go to the security module owner and peers, ! who will be responsible for posting the information received to a ! security bug.</p> <h3>Other participants</h3> *************** *** 316,336 **** complete bug report).</li> </ul> ! <p>When 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> <p>The original reporter of a security bug has the primary responsibility for deciding when that bug will be made public; --- 320,354 ---- complete bug report).</li> </ul> ! <p>When a bug is put into the security bug group, the group members, bug reporter, and others associated with the bug ! will decide by consensus, either through comments on the bug ! or the group mailing list, whether an immediate warning ! to users is appropriate and how it should be worded. The goals ! of this warning are:</p> ! ! <ul> ! <li>to inform Mozilla users and testers of potential security ! risks in the versions they are using, and what can be done to ! mitigate those risks, and</li> ! ! <li>to establish, for each bug, the amount of information a ! distributor can reveal immediately (before a fix is available) ! without putting other distributors and their customers at risk.</li> ! </ul> ! ! <p>A typical warning will mention the application or module ! affected, the affected versions, and a workaround (e.g. disabling ! JavaScript). If the group decides to publish a warning, the module owner, ! a peer, or some other person they may designate will post this ! message to the ! <a href="http://www.mozilla.org/projects/security/KnownVulnerabilities.html";> ! Known Vulnerabilities</a> page. ! Mozilla distributors who wish to inform ! their users of the existence of a vulnerability may repost any ! information from the Known Vulnerabilities page ! to their own websites, mailing lists, release notes, etc., but ! should not disclose any additional information about the bug.</p> <p>The original reporter of a security bug has the primary responsibility for deciding when that bug will be made public; *************** *** 370,376 **** </ul> <p>If 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> --- 388,394 ---- </ul> <p>If disputes arise about whether or when to disclose information ! about a security bug, the security bug 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>
