PostgreSQL Security Release Policy Draft
PostgreSQL Security Release Policy Draft
Link: http://www.postgresql.org/support/security/
Current
If you wish to report a new security vulnerability in PostgreSQL, please send an email to security@postgresql.org. For reporting non-security bugs, please see the Report a Bug page.
PostgreSQL security updates are primarily made available as minor version upgrades. You are always advised to use the latest minor version available, as it will likely also contain other non-security related fixes. All known security issues are always fixed in the next major release, when it comes out.
PGDG believes that accuracy, completeness and availability of security information is essential for our users. We choose to pool all information on this one page, allowing easy searching for vulnerabilities by a range of criteria.
The following table lists all known security issues. Please note that versions prior to 8.3 are no longer supported and vulnerabilities for these versions may not be included in this list. New vulnerabilities in these versions are no longer patched.
Vulnerabilities list which major releases they were present in, and which version they are fixed in for each. If the vulnerability was exploitable without a valid login, this is also stated. They also list a vulnerability class, but we urge all users to read the description to determine if the bug affects specific installations or not.
(List of Security Issues + Fixes here)
Draft
The PostgreSQL Global Development Group (PGDG) takes security seriously, allowing our users to place their trust in the web sites, applications and infrastructure built around PostgreSQL. Our approach covers fail-safe configuration options, a secure and robust database server as well as good integration with other security infrastructure software.
Reporting a Security Issue
If you wish to report a new security vulnerability in PostgreSQL, please send an email to our Security Team at security@postgresql.org. For reporting non-security bugs, please see the Report a Bug page.
The Security Team
The PostgreSQL Security Team consists of a small number of committers and major contributors to PostgreSQL who work on resolving reported security issues. Members of the Security Team are appointed by the PostgreSQL Core Team, and serve until they resign or are removed for inactivity.
The Security Team attempts to resolve reported security issues as quickly as possible. Depending on the difficulty of the issue, it can take a few days to a few months to resolve. While known security issues are tracked by the Security Team, the list of pending issues is not available outside of the Team.
The Packagers List
The Packagers List consists of a few dozen people who create PostgreSQL packages for distribution to other users. This includes not only those who create installers, RPMs, Debs, PPA, Ports and so forth, but also the engineers who do packaging for public Database-As-A-Service (DBaaS) clouds. In order to have packages prepared and ready to download on the day releases are announced, the Packagers list is given access to the source code of the PostgreSQL release 48 to 72 hours before release time.
If you feel that you belong on this list, but are not yet, please email pgsql-core@postgresql.org with a request to be included. This request should include:
- your full name
- your organization and/or company affiliation
- what platforms or DBaaS cloud you do packaging for
- your contact email
- names of existing trusted PostgreSQL community members who can give you a reference
For security reasons, the Packagers List needs to stay small, which means that requests which do not present a compelling reason to be on the list will be refused.
Release Policy
PostgreSQL security updates are primarily made available as minor version upgrades. You are always advised to use the latest minor version available, as it will likely also contain other non-security related fixes. All known security issues are always fixed in the next major release, when it comes out.
Disclosure Timing
Security issues which are already known to the public or for which demonstrated exploits exist "in the wild" will be discussed, fixed, and patched in the open on the normal PostgreSQL git mirrors and mailing lists.
Minor security issues are handled simply by delaying commits until 72 hours before expected release time. This narrows the window between the disclosure of security issues in code and the availability of updated packages to one which we feel is reasonable and protects our users.
If an unpublished security issue is considered sufficiently serious by the Core Team, they will issue a public notice of the date of the upcoming security release one to two weeks before the release so that users can be prepared to update their installations as soon as the release is available. This notice will not contain any details of the security issue. The PostgreSQL main git repository will then be closed to the public for the approximately three days during which packages are being built, in order to avoid premature disclosure. Criteria for seriousness in a security issue includes the number of users likely to be affected, the potential damage from exploits, and the level of existing access and knowledge required by an attacker.
At this time, we are unable to provide advance notice of security details or code to any PostgreSQL end-users or application vendors, regardless of deployment size. While we understand the desire of some end-users to have access to security information and in-progress patches as soon as they are available, we cannot put the majority of our users, who depend on packages and installers, at risk. The PostgreSQL Project may revisit this policy in the future as our resources and the general thinking around security disclosure evolve.
Supported Versions and Fixed Vulnerabilities
PGDG believes that accuracy, completeness and availability of security information is essential for our users. We choose to pool all information on this one page, allowing easy searching for vulnerabilities by a range of criteria.
The following table lists all known security issues. Please note that versions prior to 8.4 are no longer supported and vulnerabilities for these versions may not be included in this list. New vulnerabilities in these versions are no longer patched.
Vulnerabilities list which major releases they were present in, and which version they are fixed in for each. If the vulnerability was exploitable without a valid login, this is also stated. They also list a vulnerability class, but we urge all users to read the description to determine if the bug affects specific installations or not.
(List of fixes goes here)
