New upstream microreleases 12.18, 14.11, 15.6 and 16.2

[Sergio Durigan Junior]

[Impact]

 * MRE for latest stable fixes of Postgres 12, 14, and 15 released on February 2024.
 * Regular update of Postgres 16 on Noble (development release).

[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-0985

Current versions in supported releases that got updates:

 postgresql-12 | 12.17-0ubuntu0.20.04.1 | focal-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.10-0ubuntu0.22.04.1 | jammy-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-15 | 15.5-0ubuntu0.23.10.1 | mantic-security | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-16 | 16.1-1build3 | noble-proposed | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Since there is 1 CVE being fixed here, we will push this through the security pocket.

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)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan Bauer (jbauerrfid)]

Any progress on this? We are still waiting since two weeks for Postgres 12.18 to be added to the Ubuntu 20.04 LTS repos.

[Athos Ribeiro (athos-ribeiro)]

Hello, Jan.

The updates are ready now (as in https://launchpad.net/~canonical-server/+archive/ubuntu/postgresql-sru-preparation/+packages, in case you want to test them).

There was a freeze in jammy due to the latest release last week. This will land through the security pocket soon (early this week).

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-12 - 12.18-0ubuntu0.20.04.1

---------------
postgresql-12 (12.18-0ubuntu0.20.04.1) focal-security; urgency=medium

  * New upstream version (LP: #2052850).

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

    + However, one bug was fixed that could have resulted in corruption of
      GIN indexes during concurrent updates. If you suspect such
      corruption, reindex affected indexes after installing this update.

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

    + Tighten security restrictions within REFRESH MATERIALIZED
      VIEW CONCURRENTLY (Heikki Linnakangas)

      One step of a concurrent refresh command was run under weak security
      restrictions. If a materialized view's owner could persuade a
      superuser or other high-privileged user to perform a concurrent
      refresh on that view, the view's owner could control code executed
      with the privileges of the user running REFRESH.
      Fix things so that all user-determined code is run as the view's
      owner, as expected.

      The only known exploit for this error does not work in PostgreSQL
      16.0 and later, so it may be that v16 is not vulnerable in practice.

      The PostgreSQL Project thanks Pedro Gallegos for reporting this
      problem.
      (CVE-2024-0985)

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

  * d/postgresql-12.NEWS: Update.

 -- Athos Ribeiro <email address hidden> Thu, 15 Feb 2024 15:19:37 -0300

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #2052850).

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

    + However, one bug was fixed that could have resulted in corruption of
      GIN indexes during concurrent updates. If you suspect such
      corruption, reindex affected indexes after installing this update.

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

    + Tighten security restrictions within REFRESH MATERIALIZED
      VIEW CONCURRENTLY (Heikki Linnakangas)

      One step of a concurrent refresh command was run under weak security
      restrictions. If a materialized view's owner could persuade a
      superuser or other high-privileged user to perform a concurrent
      refresh on that view, the view's owner could control code executed
      with the privileges of the user running REFRESH.
      Fix things so that all user-determined code is run as the view's
      owner, as expected.

      The only known exploit for this error does not work in PostgreSQL
      16.0 and later, so it may be that v16 is not vulnerable in practice.

      The PostgreSQL Project thanks Pedro Gallegos for reporting this
      problem.
      (CVE-2024-0985)

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

  * d/postgresql-14.NEWS: Update.

 -- Sergio Durigan Junior <email address hidden> Fri, 09 Feb 2024 19:49:08 -0500

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #2052850).

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

    + However, one bug was fixed that could have resulted in corruption of
      GIN indexes during concurrent updates. If you suspect such
      corruption, reindex affected indexes after installing this update.

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

    + Tighten security restrictions within REFRESH MATERIALIZED
      VIEW CONCURRENTLY (Heikki Linnakangas)

      One step of a concurrent refresh command was run under weak security
      restrictions. If a materialized view's owner could persuade a
      superuser or other high-privileged user to perform a concurrent
      refresh on that view, the view's owner could control code executed
      with the privileges of the user running REFRESH.
      Fix things so that all user-determined code is run as the view's
      owner, as expected.

      The only known exploit for this error does not work in PostgreSQL
      16.0 and later, so it may be that v16 is not vulnerable in practice.

      The PostgreSQL Project thanks Pedro Gallegos for reporting this
      problem.
      (CVE-2024-0985)

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

  * d/postgresql-15.NEWS: Update.

 -- Sergio Durigan Junior <email address hidden> Fri, 09 Feb 2024 19:43:36 -0500