New upstream microreleases 12.19, 14.12, 15.7 and 16.3

[Sergio Durigan Junior]

[Impact]

 * MRE for latest stable fixes of Postgres 12, 14, 15 and 16 released on May 2024.

[Test Case]

 * The Postgres MREs traditionally rely on the large set of autopkgtests
   to run for verification. In a PPA, those are all already pre-checked to
   be good for this upload.

[Regression Potential]

 * Upstream tests are usually great and in addition in the Archive there
   are plenty of autopkgtests that in the past caught issues before being
   released.
   But nevertheless there always is a risk for something to break. Since
   these are general stable releases I can't pinpoint them to a most-likely area.
   - usually this works smoothly except a few test hiccups (flaky) that need to be clarified to be sure. Pre-checks will catch those to be discussed upfront (as last time)

[Other Info]

 * This is a reoccurring MRE, see below and all the references
 * CVEs addressed by this MRE:
  - CVE-2024-4317 (only applicable for versions 14, 15 and 16)

Current versions in supported releases that got updates:

 postgresql-12 | 12.18-0ubuntu0.20.04.1 | focal-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.11-0ubuntu0.22.04.1 | jammy-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-15 | 15.6-0ubuntu0.23.10.1 | mantic-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-16 | 16.2-1ubuntu4 | noble | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Since there is 1 CVE being fixed here on versions 14, 15 and 16, we will push these versions through the security pocket.
- Version 12 will be uploaded to the updates pocket, since it's not affected by the CVE.

Standing MRE - Consider last updates as template:

- https://pad.lv/1637236
- https://pad.lv/1664478
- https://pad.lv/1690730
- https://pad.lv/1713979
- https://pad.lv/1730661
- https://pad.lv/1747676
- https://pad.lv/1752271
- https://pad.lv/1786938
- https://pad.lv/1815665
- https://pad.lv/1828012
- https://pad.lv/1833211
- https://pad.lv/1839058
- https://pad.lv/1863108
- https://pad.lv/1892335
- https://pad.lv/1915254
- https://pad.lv/1928773
- https://pad.lv/1939396
- https://pad.lv/1950268
- https://pad.lv/1961127
- https://pad.lv/1973627
- https://pad.lv/1978249
- https://pad.lv/1984012
- https://pad.lv/1996770
- https://pad.lv/2006406
- https://pad.lv/2019214
- https://pad.lv/2028426
- https://pad.lv/2040469

As usual we test and prep from the PPA and then push through SRU/Security as applicable.

Once ready, the test packages should be available at https://launchpad.net/~canonical-server/+archive/ubuntu/postgresql-sru-preparation/+packages

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-14 - 14.12-0ubuntu0.22.04.1

---------------
postgresql-14 (14.12-0ubuntu0.22.04.1) jammy-security; urgency=medium

  * New upstream version (LP: #2067388).

    + A dump/restore is not required for those running 14.X.

    + However, a security vulnerability was found in the system views
      pg_stats_ext and pg_stats_ext_exprs, potentially allowing
      authenticated database users to see data they shouldn't. If this is of
      concern in your installation, follow the steps below to rectify it.

    + Also, if you are upgrading from a version earlier than 14.11, see
      those release notes as well please.

    + Restrict visibility of pg_stats_ext and pg_stats_ext_exprs entries
      to the table owner (Nathan Bossart)

      These views failed to hide statistics for expressions that involve
      columns the accessing user does not have permission to read. View
      columns such as most_common_vals might expose security-relevant
      data. The potential interactions here are not fully clear, so in the
      interest of erring on the side of safety, make rows in these views
      visible only to the owner of the associated table.

      The PostgreSQL Project thanks Lukas Fittl for reporting this
      problem.

      By itself, this fix will only fix the behavior in newly initdb'd
      database clusters. If you wish to apply this change in an existing
      cluster, you will need to do the following:

        - In each database of the cluster, run the
          /usr/share/postgresql/14/fix-CVE-2024-4317.sql script as superuser. In
          psql this would look like:

            \i /usr/share/postgresql/14/fix-CVE-2024-4317.sql

          It will not hurt to run the script more than once.

        - Do not forget to include the template0 and template1 databases,
          or the vulnerability will still exist in databases you create
          later. To fix template0, you'll need to temporarily make it accept
          connections. Do that with:

            ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

          and then after fixing template0, undo it with:

            ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

      (CVE-2024-4317)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/14/release-14-12.html

  * d/postgresql-14.NEWS: Update.

 -- Sergio Durigan Junior <email address hidden> Tue, 28 May 2024 09:51:10 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-15 - 15.7-0ubuntu0.23.10.1

---------------
postgresql-15 (15.7-0ubuntu0.23.10.1) mantic-security; urgency=medium

  * New upstream version (LP: #2067388).

    + A dump/restore is not required for those running 15.X.

    + However, a security vulnerability was found in the system views
      pg_stats_ext and pg_stats_ext_exprs, potentially allowing
      authenticated database users to see data they shouldn't. If this is of
      concern in your installation, follow the steps below to rectify it.

    + Also, if you are upgrading from a version earlier than 15.6, see
      those release notes as well please.

    + Restrict visibility of pg_stats_ext and pg_stats_ext_exprs entries
      to the table owner (Nathan Bossart)

      These views failed to hide statistics for expressions that involve
      columns the accessing user does not have permission to read. View
      columns such as most_common_vals might expose security-relevant
      data. The potential interactions here are not fully clear, so in the
      interest of erring on the side of safety, make rows in these views
      visible only to the owner of the associated table.

      The PostgreSQL Project thanks Lukas Fittl for reporting this
      problem.

      By itself, this fix will only fix the behavior in newly initdb'd
      database clusters. If you wish to apply this change in an existing
      cluster, you will need to do the following:

        - In each database of the cluster, run the
          /usr/share/postgresql/15/fix-CVE-2024-4317.sql script as superuser. In
          psql this would look like:

            \i /usr/share/postgresql/15/fix-CVE-2024-4317.sql

          It will not hurt to run the script more than once.

        - Do not forget to include the template0 and template1 databases,
          or the vulnerability will still exist in databases you create
          later. To fix template0, you'll need to temporarily make it accept
          connections. Do that with:

            ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

          and then after fixing template0, undo it with:

            ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

      (CVE-2024-4317)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/15/release-15-7.html.

  * d/postgresql-15.NEWS: Update.

 -- Sergio Durigan Junior <email address hidden> Tue, 28 May 2024 10:27:51 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-16 - 16.3-0ubuntu0.24.04.1

---------------
postgresql-16 (16.3-0ubuntu0.24.04.1) noble-security; urgency=medium

  * New upstream version (LP: #2067388).

    + A dump/restore is not required for those running 16.X.

    + However, a security vulnerability was found in the system views
      pg_stats_ext and pg_stats_ext_exprs, potentially allowing
      authenticated database users to see data they shouldn't. If this is of
      concern in your installation, follow the steps below to rectify it.

    + Also, if you are upgrading from a version earlier than 16.2, see
      those release notes as well please.

    + Restrict visibility of pg_stats_ext and pg_stats_ext_exprs entries
      to the table owner (Nathan Bossart)

      These views failed to hide statistics for expressions that involve
      columns the accessing user does not have permission to read. View
      columns such as most_common_vals might expose security-relevant
      data. The potential interactions here are not fully clear, so in the
      interest of erring on the side of safety, make rows in these views
      visible only to the owner of the associated table.

      The PostgreSQL Project thanks Lukas Fittl for reporting this
      problem.

      By itself, this fix will only fix the behavior in newly initdb'd
      database clusters. If you wish to apply this change in an existing
      cluster, you will need to do the following:

        - In each database of the cluster, run the
          /usr/share/postgresql/16/fix-CVE-2024-4317.sql script as superuser. In
          psql this would look like:

            \i /usr/share/postgresql/16/fix-CVE-2024-4317.sql

          It will not hurt to run the script more than once.

        - Do not forget to include the template0 and template1 databases,
          or the vulnerability will still exist in databases you create
          later. To fix template0, you'll need to temporarily make it accept
          connections. Do that with:

            ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

          and then after fixing template0, undo it with:

            ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

      (CVE-2024-4317)

    + Details about these and many further changes can be found at:
      https://www.postgresql.org/docs/16/release-16-3.html.

  * d/postgresql-16.NEWS: Update.

 -- Sergio Durigan Junior <email address hidden> Wed, 29 May 2024 13:16:10 -0400

[Chris Halse Rogers (raof)]

Hello Sergio, or anyone else affected,

Accepted postgresql-12 into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postgresql-12/12.19-0ubuntu0.20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted postgresql-12 (12.19-0ubuntu0.20.04.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

check-postgres/2.25.0-1 (armhf)
hypopg/unknown (armhf)
ip4r/unknown (armhf)
jsquery/unknown (armhf)
libdbd-pg-perl/unknown (armhf)
osm2pgrouting/unknown (armhf)
pgl-ddl-deploy/1.7.0-1 (armhf)
pgsql-asn1oid/unknown (armhf)
pgtap/unknown (armhf)
pldebugger/unknown (armhf)
postgresql-mysql-fdw/unknown (armhf)
postgresql-numeral/unknown (armhf)
postgresql-pgmp/unknown (armhf)
prefix/unknown (armhf)
ruby-dataobjects-postgres/unknown (armhf)
sqitch/unknown (armhf)
sqlsmith/unknown (armhf)
toastinfo/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#postgresql-12

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Sergio Durigan Junior (sergiodj)]

As usual with non-security updates, we use the results of autopkgtest in order to perform the verification. In this case, all tests succeeded for postgresql-12 in Focal. Therefore, tagging as verification-done-focal.