2020-07-24 databases/postgresql94-client: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-contrib: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-docs: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-pgtcl: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-plpython: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-server: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-pltcl: PostgreSQL-9.4 has reached end-of-life
2020-07-24 databases/postgresql94-plperl: PostgreSQL-9.4 has reached end-of-life

Final release was in Fabruary 2020.

WWW:	https://www.postgresql.org/support/versioning/

Also, fix build problems with plperl and plpython  for 9.4

supported versions of our database system, including 12.2, 11.7, 10.12,
9.6.17, 9.5.21, and 9.4.26. This release fixes one security issue found
in the PostgreSQL server and over 75 bugs reported over the last three
months.

Users should plan to update as soon as possible.

PostgreSQL 9.4 Now EOL

This is the last release for PostgreSQL 9.4, which will no longer
receive security updates and bug fixes. PostgreSQL 9.4 introduced new
features such as JSONB support, the `ALTER SYSTEM` command, the ability
to stream logical changes to an output plugin, and more:

 https://www.postgresql.org/about/news/1557/
 https://www.postgresql.org/docs/9.4/release-9-4.html

While we are very proud of this release, these features are also found
in newer versions of PostgreSQL. Many of these features have also
received improvements, and, per our versioning policy, it is time to
retire PostgreSQL 9.4.

To receive continued support, we suggest that you make plans to upgrade
to a newer, supported version of PostgreSQL. Please see the PostgreSQL
versioning policy for more information.

Security Issues

* CVE-2020-1720: `ALTER ... DEPENDS ON EXTENSION` is missing
authorization checks.

Versions Affected: 9.6 - 12

The `ALTER ... DEPENDS ON EXTENSION` sub-commands do not perform
authorization checks, which can allow an unprivileged user to  drop any
function, procedure, materialized view, index, or trigger under certain
conditions. This attack is possible if an administrator has installed an
extension and an unprivileged user can `CREATE`, or an extension owner
either executes `DROP EXTENSION` predictably or can be convinced to
execute `DROP EXTENSION`.

Release notes: https://www.postgresql.org/docs/current/release.html

The PostgreSQL Global Development Group has released an update to all
supported versions of our database system, including 12.1, 11.6, 10.11,
9.6.16, 9.5.20, and 9.4.25. This release fixes over 50 bugs reported
over the last three months.

PostgreSQL 9.4 will stop receiving fixes on February 13, 2020, which is
the next planned cumulative update release. We suggest that you make
plans to upgrade to a newer, supported version of PostgreSQL. Please see
our versioning policy for more information:

This update also fixes over 50 bugs that were reported in the last
several months. Some of these issues affect only version 12, but may
also affect all supported versions.

Specific change to the FreeBSD port:
Starting now, the default for TZDATA has changed to using the underlying OS'
time zone database instead of the one built in to PostgreSQL. This change is
made since PostgreSQL will not release a patch in the event where the time zone
database changes, whereas FreeBSD will.

Release notes:	https://www.postgresql.org/about/news/1994/
URL:		https://www.postgresql.org/support/versioning/

supported versions of our database system, including 11.5, 10.10,
9.6.15, 9.5.19, and 9.4.24, as well as the third beta of PostgreSQL 12.
This release fixes two security issues in the PostgreSQL server, two
security issues found in one of the PostgreSQL Windows installers, and
over 40 bugs reported since the previous release.

Users should install these updates as soon as possible.

A Note on the PostgreSQL 12 Beta
================================

In the spirit of the open source PostgreSQL community, we strongly
encourage you to test the new features of PostgreSQL 12 in your database
systems to help us eliminate any bugs or other issues that may exist.
While we do not advise you to run PostgreSQL 12 Beta 3 in your
production environments, we encourage you to find ways to run your
typical application workloads against this beta release.

Your testing and feedback will help the community ensure that the
PostgreSQL 12 release upholds our standards of providing a stable,
reliable release of the world's most advanced open source relational
database.

Security Issues
===============

Two security vulnerabilities have been closed by this release:

* CVE-2019-10208: `TYPE` in `pg_temp` executes arbitrary SQL during
`SECURITY DEFINER` execution

Versions Affected: 9.4 - 11

Given a suitable `SECURITY DEFINER` function, an attacker can execute
arbitrary SQL under the identity of the function owner.  An attack
requires `EXECUTE` permission on the function, which must itself contain
a function call having inexact argument type match.  For example,
`length('foo'::varchar)` and `length('foo')` are inexact, while
`length('foo'::text)` is exact.  As part of exploiting this
vulnerability, the attacker uses `CREATE DOMAIN` to create a type in a
`pg_temp` schema. The attack pattern and fix are similar to that for
CVE-2007-2138.

Writing `SECURITY DEFINER` functions continues to require following the
considerations noted in the documentation:

https://www.postgresql.org/docs/devel/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY

The PostgreSQL project thanks Tom Lane for reporting this problem.

* CVE-2019-10209: Memory disclosure in cross-type comparison for hashed
subplan

Versions Affected: 11

In a database containing hypothetical, user-defined hash equality operators, an attacker could read arbitrary bytes of server memory. For an attack to become possible, a superuser would need to create unusual operators. It is possible for operators not purpose-crafted for attack to have the properties that enable an attack, but we are not aware of specific examples.

The PostgreSQL project thanks Andreas Seltenreich for reporting this problem.

as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.

This includes ports
 - with USE_GCC=yes or USE_GCC=any,
 - with USES=fortran,
 - using Mk/bsd.octave.mk which in turn features USES=fortran, and
 - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
   c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.

PR:		238330

The PostgreSQL Global Development Group has released an update to all supported
versions of our database system, including 11.4, 10.9, 9.6.14, 9.5.18, and
9.4.23, as well as the second beta of PostgreSQL 12. This release fixes one
security issue and over 25 bugs since the previous cumulative update in May.

This release is made outside of the normal update release schedule as the
security vulnerability was determined to be critical enough to distribute the
fix as quickly as possible. Users who are running PostgreSQL 10, PostgreSQL 11,
or the PostgreSQL 12 beta should upgrade as soon as possible.

All other users should plan to apply this update at the next scheduled
downtime.

Release notes:	https://www.postgresql.org/about/news/1949/
Security:	245629d4-991e-11e9-82aa-6cc21735f730

supported versions of our database system, including 11.3, 10.8, 9.6.13,
9.5.17, and 9.4.22. This release fixes two security issues in the
PostgreSQL server, a security issue found in two of the PostgreSQL
Windows installers, and over 60 bugs reported over the last three months.

Security:	CVE-2019-10129: Memory disclosure in partition routing

Prior to this release, a user running PostgreSQL 11 can read arbitrary
bytes of server memory by executing a purpose-crafted INSERT statement
to a partitioned table.

Security:	CVE-2019-10130: Selectivity estimators bypass row security policies

PostgreSQL maintains statistics for tables by sampling data available in
columns; this data is consulted during the query planning process. Prior
to this release, a user able to execute SQL queries with permissions to
read a given column could craft a leaky operator that could read
whatever data had been sampled from that column.  If this happened to
include values from rows that the user is forbidden to see by a row
security policy, the user could effectively bypass the policy.  This is
fixed by only allowing a non-leakproof operator to use this data if
there are no relevant row security policies for the table.

This issue is present in PostgreSQL 9.5, 9.6, 10, and 11. The PostgreSQL
project thanks Dean Rasheed for reporting this problem.

Also fix a FreeBSD port problem with LLVM [1] and add promote command
to `service postgresql` [2]

PR:	236100, 234879
Submitted by:	tomonori.usaka@ubin.jp [1], Trix Farrar [2]

I've had to bump revision for several slaves here, but most will not
be rebuilt, except the -client slaves.  Apologies for anyone having
to rebuild -clients unnecessarily, but it's not a heavy task- better safe
than sorry.

PR:		ports/236156
Reported by:	Andrew Dunstan (PostgreSQL), koobs, Dmitri Goutnik