Page tree
Skip to end of metadata
Go to start of metadata

Our Security Policy

Reporting a vulnerability

To report a vulnerability you can either email security /at/ or open a 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.

Security team process

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.

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/, not dev.
  • Generally figure out which version(s) are impacted by the issue.
  • Write up a general vulnerability statement explaining the issue.
  • 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 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 mailing-list:distros.
  • 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 for more information.

  • No labels