-
postgresql-9.5 (9.5.7-0ubuntu0.16.10) yakkety; urgency=medium
* New upstream release (LP: #1690730)
- Restrict visibility of pg_user_mappings.umoptions, to protect passwords
stored as user mapping options (CVE-2017-7486)
- Prevent exposure of statistical information via leaky operators
(CVE-2017-7484)
- Restore libpq's recognition of the PGREQUIRESSL environment variable
(CVE-2017-7485)
- A dump/restore is not required for those running 9.5.X.
- However, if you use foreign data servers that make use of user passwords
for authentication, see the first changelog entry.
- Also, if you are using third-party replication tools that depend on
"logical decoding", see the fourth changelog entry.
- Details about other changes at full changelog:
https://www.postgresql.org/docs/9.5/static/release-9-5-7.html
-- Christian Ehrhardt <email address hidden> Mon, 15 May 2017 08:46:09 +0200
-
postgresql-9.5 (9.5.6-0ubuntu0.16.10) yakkety; urgency=medium
* New upstream release (LP: #1664478)
- Fix a race condition that could cause indexes built with CREATE INDEX
CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane).
If CREATE INDEX CONCURRENTLY was used to build an index that depends on
a column not previously indexed, then rows inserted or updated by
transactions that ran concurrently with the CREATE INDEX command could
have received incorrect index entries. If you suspect this may have
happened, the most reliable solution is to rebuild affected indexes
after installing this update
- Details about other changes:
http://www.postgresql.org/docs/9.5/static/release-9-5-6.html
-- Christian Ehrhardt <email address hidden> Tue, 14 Feb 2017 09:28:18 +0100
-
postgresql-9.5 (9.5.5-0ubuntu0.16.10) yakkety; urgency=medium
* New upstream bug fix release (LP: #1637236)
- Fix WAL-logging of truncation of relation free space maps and visibility
maps.
It was possible for these files to not be correctly restored during
crash recovery, or to be written incorrectly on a standby server. Bogus
entries in a free space map could lead to attempts to access pages that
have been truncated away from the relation itself, typically producing
errors like "could not read block XXX: read only 0 of 8192 bytes".
Checksum failures in the visibility map are also possible, if
checksumming is enabled.
Procedures for determining whether there is a problem and repairing it
if so are discussed at
https://wiki.postgresql.org/wiki/Free_Space_Map_Problems.
- Details about other changes:
http://www.postgresql.org/docs/9.5/static/release-9-5-5.html
-- Martin Pitt <email address hidden> Thu, 27 Oct 2016 17:51:11 +0200
-
postgresql-9.5 (9.5.4-1) unstable; urgency=medium
* New upstream version.
+ Fix possible mis-evaluation of nested CASE-WHEN expressions
(Heikki Linnakangas, Michael Paquier, Tom Lane)
A CASE expression appearing within the test value subexpression of
another CASE could become confused about whether its own test value was
null or not. Also, inlining of a SQL function implementing the equality
operator used by a CASE expression could result in passing the wrong
test value to functions called within a CASE expression in the SQL
function's body. If the test values were of different data types, a
crash might result; moreover such situations could be abused to allow
disclosure of portions of server memory. (CVE-2016-5423)
+ Fix client programs' handling of special characters in database and role
names (Noah Misch, Nathan Bossart, Michael Paquier)
Numerous places in vacuumdb and other client programs could become
confused by database and role names containing double quotes or
backslashes. Tighten up quoting rules to make that safe. Also, ensure
that when a conninfo string is used as a database name parameter to
these programs, it is correctly treated as such throughout.
Fix handling of paired double quotes in psql's \connect and \password
commands to match the documentation.
Introduce a new -reuse-previous option in psql's \connect command to
allow explicit control of whether to re-use connection parameters from a
previous connection. (Without this, the choice is based on whether the
database name looks like a conninfo string, as before.) This allows
secure handling of database names containing special characters in
pg_dumpall scripts.
pg_dumpall now refuses to deal with database and role names containing
carriage returns or newlines, as it seems impractical to quote those
characters safely on Windows. In future we may reject such names on the
server side, but that step has not been taken yet.
These are considered security fixes because crafted object names
containing special characters could have been used to execute commands
with superuser privileges the next time a superuser executes pg_dumpall
or other routine maintenance operations. (CVE-2016-5424)
* Remove conditional multi-arch compilation, all supported dists are
multi-arched now.
* Use explicit xz compression for wheezy and precise
-- Christoph Berg <email address hidden> Tue, 09 Aug 2016 17:19:59 +0200
-
postgresql-9.5 (9.5.3-1) unstable; urgency=medium
* New upstream version.
* rules: Use host architecture for all architecture checks.
* Use POSIX semaphores on hurd. They don't work yet, but have better chances
of eventually getting implemented. Closes: #820743.
* Bump minimum postgresql-common version for postgresql-9.5 to 158 due to
PG_OOM_ADJUST_FILE.
-- Christoph Berg <email address hidden> Tue, 10 May 2016 10:18:45 +0200
-
postgresql-9.5 (9.5.2-1) unstable; urgency=medium
* New upstream version.
+ Disable abbreviated keys for string sorting in non-C locales
(Robert Haas)
PostgreSQL 9.5 introduced logic for speeding up comparisons of string
data types by using the standard C library function strxfrm() as a
substitute for strcoll(). It now emerges that most versions of glibc
(Linux's implementation of the C library) have buggy implementations of
strxfrm() that, in some locales, can produce string comparison results
that do not match strcoll(). Until this problem can be better
characterized, disable the optimization in all non-C locales. (C locale
is safe since it uses neither strcoll() nor strxfrm().)
Unfortunately, this problem affects not only sorting but also entry
ordering in B-tree indexes, which means that B-tree indexes on text,
varchar, or char columns may now be corrupt if they sort according to an
affected locale and were built or modified under PostgreSQL 9.5.0 or
9.5.1. Users should REINDEX indexes that might be affected.
It is not possible at this time to give an exhaustive list of
known-affected locales. C locale is known safe, and there is no
evidence of trouble in English-based locales such as en_US, but some
other popular locales such as de_DE are affected in most glibc versions.
+ Maintain row-security status properly in cached plans (Stephen Frost)
In a session that performs queries as more than one role, the plan cache
might incorrectly re-use a plan that was generated for another role ID,
thus possibly applying the wrong set of policies when row-level security
(RLS) is in use. (CVE-2016-2193)
+ Add must-be-superuser checks to some new contrib/pageinspect functions
(Andreas Seltenreich)
Most functions in the pageinspect extension that inspect bytea values
disallow calls by non-superusers, but brin_page_type() and
brin_metapage_info() failed to do so. Passing contrived bytea values to
them might crash the server or disclose a few bytes of server memory.
Add the missing permissions checks to prevent misuse. (CVE-2016-3065)
* 02-relax-sslkey-permscheck.patch: Replace with what went upstream in 9.6.
* Stop suggesting the use of identd.
* Modernize server package description.
* Recommend sysstat.
-- Christoph Berg <email address hidden> Tue, 29 Mar 2016 12:22:08 +0200
