Package "libpq-dev"

  postgresql-9.5 (9.5.12-0ubuntu0.16.04) xenial-security; urgency=medium

  * New upstream release (LP: #1752271)
    If you run an installation in which not all users are mutually
    trusting, or if you maintain an application or extension that is
    intended for use in arbitrary situations, it is strongly recommended
    that you read the documentation changes described in the first changelog
    entry below, and take suitable steps to ensure that your installation or
    code is secure.

    Also, the changes described in the second changelog entry below may
    cause functions used in index expressions or materialized views to fail
    during auto-analyze, or when reloading from a dump. After upgrading,
    monitor the server logs for such problems, and fix affected functions.

    - Document how to configure installations and applications to guard
      against search-path-dependent trojan-horse attacks from other users

      Using a search_path setting that includes any schemas writable by a
      hostile user enables that user to capture control of queries and then
      run arbitrary SQL code with the permissions of the attacked user. While
      it is possible to write queries that are proof against such hijacking,
      it is notationally tedious, and it's very easy to overlook holes.
      Therefore, we now recommend configurations in which no untrusted schemas
      appear in one's search path.
      (CVE-2018-1058)

    - Avoid use of insecure search_path settings in pg_dump and other client
      programs

      pg_dump, pg_upgrade, vacuumdb and other PostgreSQL-provided applications
      were themselves vulnerable to the type of hijacking described in the
      previous changelog entry; since these applications are commonly run by
      superusers, they present particularly attractive targets. To make them
      secure whether or not the installation as a whole has been secured,
      modify them to include only the pg_catalog schema in their search_path
      settings. Autovacuum worker processes now do the same, as well.

      In cases where user-provided functions are indirectly executed by these
      programs -- for example, user-provided functions in index expressions --
      the tighter search_path may result in errors, which will need to be
      corrected by adjusting those user-provided functions to not assume
      anything about what search path they are invoked under. That has always
      been good practice, but now it will be necessary for correct behavior.
      (CVE-2018-1058)

    - Details about other changes can be found at
      https://www.postgresql.org/docs/9.5/static/release-9-5-12.html

 -- Christian Ehrhardt <email address hidden> Wed, 28 Feb 2018 09:59:08 +0100

  postgresql-9.5 (9.5.11-0ubuntu0.16.04) xenial-security; urgency=medium

  * New upstream release (LP: #1747676)
    - Ensure that all temporary files made by pg_upgrade are non-world-readable
      (CVE-2018-1053)
    - Details about other changes at full changelog:
      https://www.postgresql.org/docs/9.5/static/release-9-5-11.html

 -- Christian Ehrhardt <email address hidden> Tue, 06 Feb 2018 15:20:02 +0100

  postgresql-9.5 (9.5.10-0ubuntu0.16.04) xenial-security; urgency=medium

  * New upstream release (LP: #1730661)
    - Previously, a race condition allowed some table rows to be omitted from
      the index. It may be necessary to reindex existing BRIN indexes to
      recover from past occurrences of this problem.
    - Details about other changes at full changelog:
      https://www.postgresql.org/docs/9.5/static/release-9-5-10.html

 -- Christian Ehrhardt <email address hidden> Tue, 07 Nov 2017 14:33:50 +0100

  postgresql-9.5 (9.5.8-0ubuntu0.16.04.1) xenial-security; urgency=medium

  * SECURITY UPDATE: Update to 9.5.8 to fix security issues
    - Further restrict visibility of pg_user_mappings.umoptions, to protect
      passwords stored as user mapping options (CVE-2017-7547)
    - Disallow empty passwords in all password-based authentication methods
      (CVE-2017-7546)
    - Make lo_put() check for UPDATE privilege on the target large object
      (CVE-2017-7548)

 -- Marc Deslauriers <email address hidden> Mon, 14 Aug 2017 08:45:32 -0400

  postgresql-9.5 (9.5.4-0ubuntu0.16.04) xenial-security; urgency=medium

  * New upstream security/bug fix release (LP: #1614113)
    - Fix possible mis-evaluation of nested CASE-WHEN expressions
      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
      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)

    - Details about other fixes:
      https://www.postgresql.org/docs/9.5/static/release-9-5-4.html

 -- Martin Pitt <email address hidden> Wed, 17 Aug 2016 16:12:33 +0200