Handling Security Issues
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 firstname.lastname@example.org is the recommended contact point for all inquiries about security issues. It currently points at email@example.com.
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
- Tatsuo Ishii
- Jonathan Katz
- Magnus Hagander
- Michael Paquier
- Noah Misch
- Peter Eisentraut
- Robert Haas
- Stephen Frost
- Simon Riggs
- 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.
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.