...
To report a vulnerability you can either email security /at/ spamassassin.apache.org or open a bugzilla Bugzilla issue being very careful to set the Component to Security so that it is not generally visible. If you create the bug report you will have access to it, as will the security team.
...
The Apache process for vulnerability handling by committers is listed at Vulnerability Handling. Our writeup here is intended to be our version of the steps, but compatible with that, which should be read before or along with reading the rest of this page. This writeup is our compatible version, step numbers referring to those in that document.
Once a potential vulnerability is reported to the SpamAssassin committers, the process has satisfied steps 1, 2, and 3.
- If the reporter has
...
- opened a Bugzilla issue reporting the vulnerability, ensure that the Component has been set to Security. If the reporter has not already done so, create a new issue with Security component and add the reporter to its Cc list. This will satisfy step 4.
- Determine if this is a valid issue to be fixed and if it should be handled as a security vulnerability. Add comments and change the status of the issue to VERIFIED, CLOSED, change the component if not a security issue, as appropriate. This action with an explanatory comment satisfies steps 5-7.
- If it is a valid new security issue, determine the versions impacted by the issue, and use the comments in the issue to discuss and write up a description of the vulnerability that will allow preparation of
- 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 one or more CVEs, following the instructions in step 8 at Vulnerability Handling..
- When the ASF security team sends the CVE, follow steps 9 and its related step 11 to begin preparation of the CVE report and announcement text.
- Post discussions of the vulnerability, proposed fixes, drafts of the announcement text, logs of the svn commits, and decisions on a release schedule that contains the fix, all in comments in the Bugzilla issue. The emails sent by Bugzilla will satisfy steps 10, 12, and 13.
- Note that to satisfy step 14, the svn commit message should not mention that it is for a security vulnerability, and also should be worded generally enough that it is not likely to be recognizable as being for this vulnerability even after the public sees the announcement text that is being prepared. Also, unlike non-security issues which are closed in Bugzilla once the fix is committed, leave this issue in Open state until the SpamAssassin release containing the fix is prepared. That prevents people without full access to the issue from matching up the time of closing of the issue with time of svn commit.
- Consider whether there are compelling reasons for early disclosure of the vulnerability to the trusted vendors Notifications are made in advance to the private mailing list described at mailing-list:distros (note: read their different addresses for issues that are to be made public within 14 days vs those that will be longer), and or anyone the else 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.
- . The default steps do not include any early disclosure. However there could be circumstances in which it is deemed important to let vendors incorporate patches for a vulnerability before it becomes public knowledge.
- Prepare a release of SpamAssassin that contains the fix of the issue (step 15).
- Announce the vulnerability as per step 16.
- Note that we skip step 17 which says to edit the svn log to add the CVE identifier to the commit message of the fix. As explained in the above note regarding step 14, we want to obfuscate the connection between the specific commits and the security vulnerability from people who do not already have read access to the Bugzilla issue. Since the process described here results in both the CVE identifier and the commits appearing the issue comments, anyone who does have read access to the issue will be able to find the commits by searching in Bugzilla for the CVE identifierpatch 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.