The current version can be found at http://www.mozilla.org/projects/security/security-bugs-policy.html.
Mitchell
Mitchell Baker wrote:
I am proposing a slight change to the policy on handling Mozilla Security Bugs. This proposed change has been reviewed and approved by the security group.
The proposed change allows an employee with information important to his or her company's product to share that information within his or her company. This is necessary to allow distributors of Mozilla technology to function effectively. It is not enough for an individual to know of a security flaw in Mozilla if s/he is prevented from describing it and allowing a distributor to make rational decisions about their product. I believe the change reflects the existing intent of the security group, but not our stated policy.
The change is in the section titled "Disclosure of Security Vulnerabilities" and that section is below. The proposed change is in green. (The version number and date of the document would of course change as well.) The entire document (not reflecting the proposed change) can be found at http://mozilla.org/projects/security/security-bugs-policy.html
The document has HTML formatting, which I have not tried to remove for this message.
Mitchell
Disclosure of security vulnerabilities
The security module owner, peers, and other members of the Mozilla security bug group will/ not/ be asked to sign formal nondisclosure agreements or other legal paperwork. However we do expect members of the group
* not to disclose security bug information to others who are not
members of the Mozilla security bug group or are not otherwise
involved in resolving the bug, /_except that_/ if a member of the
Mozilla security bug group is employed by a distributor of
Mozilla-based products, then that member may share such
information within that distributor, provided that this
information is shared only with those who have a need to know,
only to the extent they need to know, and such information is
labeled and treated as the organization generally treats
confidential material
* not to post descriptions of exploits in public forums like
newsgroups, and
* to be careful in whom they add to the CC field of a bug (since all
those CC'd on a security bug potentially have access to the
complete bug report).
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:
* 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
* 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.
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 Known Vulnerabilities <http://www.mozilla.org/projects/security/known-vulnerabilities.html> page (which will be the authoritative source for this information) and will also send a copy of this message to an appropriate moderated mailing list and/or newsgroup (e.g., netscape.public.mozilla.announce and/or some other newsgroup/list established specifically for this purpose). 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.
The original reporter of a security bug may decide when that bug report will be made public; disclosure is done by clearing the bug's "Security-Sensitive" flag, after which the bug will revert to being an ordinary bug. We believe that investing this power in the bug reporter simply acknowledges reality: Nothing prevents the person reporting a security bug from publicizing information about the bug by posting it to channels outside the context of the Mozilla project. By not doing so, and by instead choosing to report bugs through the standard Bugzilla processes, the bug reporter is doing a positive service to the Mozilla project; thus it makes sense that the bug reporter should be able to decide when the relevant Bugzilla data should be made public.
However we will ask all individuals and organizations reporting security bugs through Bugzilla to follow the voluntary guidelines below:
* Before making a security bug world-readable, please provide a few
days notice to the Mozilla security bug group by sending email to
the private security bug group mailing list.
* Please try not to keep bugs in the security-sensitive category for
an unreasonably long amount of time.
* Please try to be understanding and accomodating if a Mozilla
distributor has a legitimate need to keep a bug in the
security-sensitive category for some reasonable additional time
period, e.g., to get a new release distributed to users.
(Regarding this point, if all Mozilla distributors have a
representative on the security bug group, then even if a bug
remains in the security-sensitive category all affected
distributors can still be informed and take appropriate action.)
The security module owner will be the primary person responsible for ensuring that security bug reports are investigated and publicly disclosed in a timely manner, and that such bug reports do not remain in the Bugzilla database uninvestigated and/or undisclosed. 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."
A final point about duplicate bug reports: Note that security bugs marked as duplicates are still considered separate as far as disclosure is concerned. Thus, for example, if a particular security vulnerability is reported initially and then is independently reported again by someone else, each bug reporter retains control over whether to publicly disclose their own bug, but their decision will not affect disclosure for the bug reported by the other person.
