Handling Security Issues

From PostgreSQL wiki
Jump to navigationJump to search

This page contains information for developers on how to deal with security issues and how to prepare a security release.

Note: If you are a user who wants to report a security issue or who wants to learn about how the PostgreSQL project deals with security issues, please go to http://www.postgresql.org/support/security. The wiki page you are looking at is aimed at developers.


The email address security@postgresql.org is the recommended contact point for all inquiries about security issues. It currently points at pgsql-security@postgresql.org.

Security team

The security team is a closed-subscription list whose purpose is to be able to discuss security issues in a controlled group. The current members are:

  • Álvaro Herrera
  • Andres Freund
  • Andrew Dunstan
  • Bruce Momjian
  • Dave Page
  • Greg Stark
  • Heikki Linnakangas
  • Joe Conway
  • Jonathan Katz
  • Magnus Hagander
  • Michael Paquier
  • Noah Misch
  • Peter Eisentraut
  • Robert Haas
  • Stefan Kaltenbrunner
  • Tom Lane

Responding to security bug reports

Respond to a security bug report reported via the security@ address in the same way as you would with a normal bug report on pgsql-bugs. The only difference is that the issue should not be disclosed to anyone outside the security team and the original reporter.

Committing patches for security issues

If the git commit log message for a commit matches


then the message on pgsql-committers will be held for moderation. This facility should be applied when committing a patch for a security issue, so that details of the fix don't get broadcast to the world before the release including the fix is made. See this example for a commit message where this was done. As in that example, the recommended style is something like "Security: CVE-number" or some other reference to the reason for the security marker.

CVE numbers

A CVE number should be requested for every security issue. This number should be included in all the commit messages, announcements, and so on. A document describing the process can be found on developer.postgresql.org at ~petere/can-request.txt (only available with shell access, because it is not a public document). The person who drives the process of fixing the issue and preparing the security release (often Tom Lane) is usually the one who deals with requesting the CVE numbers.