Our Security Policy

Once a potential vulnerability is reported to the committers, and has been verified to be an issue, here's what to do (based on what we did for bug 5480):

• Open a bugzilla Security bug to track the issue/discuss it; ensure discussion cc's security /at/ spamassassin.apache.org, not dev.

• Generally figure out which version(s) are impacted by the issue.

• Write up a general vulnerability statement explaining the issue.

• Request a CVE. security /at/ apache.org last said to contact Mark J Cox <mark /at/ awe.com> to get a number.

• Notifications are made in advance to the vendor-sec mailing list <vendor-sec /at/ lst.de> and anyone the committers feel like informing, as long as it is kept private. notifications contain the vulnerability statement, CVE info, and patch (if possible). (We may need to override on an issue-by-issue basis; for certain issues (e.g. remote root hole in the default configuration via malformed mail messages or something), we may want to keep these *extremely* secret and be very careful with vendor/packager notification.)

• Public releases and announcements are made at an agreed upon time, ideally 1-2 business days after the notification to vendor-sec.

• Tarballs are prepared "in secret" without committing anything to SVN or discussing on a public list.

• patch is not committed to SVN until the tarballs are released to the public.

Additional guidance may be required. See http://www.apache.org/security/ for more information.