New upstream microreleases 10.21, 12.11, 13.7 and 14.3

[Athos Ribeiro]

[Impact]

 * MRE for latest stable fixes of Postgres released in May 2022

[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 catched 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 for 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 this time:
   - CVE-2022-1552 (v10, v12, v13, v14)

Current versions in supported releases that got updates:
 postgresql-10 | 10.20-0ubuntu0.18.04.1 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x
 postgresql-12 | 12.10-0ubuntu0.20.04.1 | focal-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-13 | 13.6-0ubuntu0.21.10.1 | impish-updates | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 postgresql-14 | 14.2-1ubuntu1 | jammy | source, amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Special cases:
- Kinetic has already synced from Debian as usual (14.3).

Standing MRE - Consider last updates as template:
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730
- pad.lv/1713979
- pad.lv/1730661
- pad.lv/1747676
- pad.lv/1752271
- pad.lv/1786938
- pad.lv/1815665
- pad.lv/1828012
- pad.lv/1833211
- pad.lv/1839058
- pad.lv/1863108
- pad.lv/1892335
- pad.lv/1915254
- pad.lv/1928773
- pad.lv/1939396
- pad.lv/1950268
- pad.lv/1961127

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-10 - 10.21-0ubuntu0.18.04.1

---------------
postgresql-10 (10.21-0ubuntu0.18.04.1) bionic-security; urgency=medium

  * New upstream version (LP: #1973627).

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

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

    + Confine additional operations within "security restricted operation"
      sandboxes (Sergey Shinderuk, Noah Misch).

      Autovacuum, CLUSTER, CREATE INDEX, REINDEX, REFRESH MATERIALIZED VIEW,
      and pg_amcheck activated the "security restricted operation" protection
      mechanism too late, or even not at all in some code paths. A user having
      permission to create non-temporary objects within a database could
      define an object that would execute arbitrary SQL code with superuser
      permissions the next time that autovacuum processed the object, or that
      some superuser ran one of the affected commands against it.

      The PostgreSQL Project thanks Alexander Lakhin for reporting this
      problem.
      (CVE-2022-1552)

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

 -- Sergio Durigan Junior <email address hidden> Tue, 17 May 2022 21:58:23 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package postgresql-13 - 13.7-0ubuntu0.21.10.1

---------------
postgresql-13 (13.7-0ubuntu0.21.10.1) impish-security; urgency=medium

  * New upstream version (LP: #1973627).

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

    + However, if you have any GiST indexes on columns of type ltree (supplied
      by the contrib/ltree extension), you should re-index them after updating.
      See the upstream changelog linked below for further information.

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

    + Confine additional operations within "security restricted operation"
      sandboxes (Sergey Shinderuk, Noah Misch).

      Autovacuum, CLUSTER, CREATE INDEX, REINDEX, REFRESH MATERIALIZED VIEW,
      and pg_amcheck activated the "security restricted operation" protection
      mechanism too late, or even not at all in some code paths. A user having
      permission to create non-temporary objects within a database could
      define an object that would execute arbitrary SQL code with superuser
      permissions the next time that autovacuum processed the object, or that
      some superuser ran one of the affected commands against it.

      The PostgreSQL Project thanks Alexander Lakhin for reporting this
      problem.
      (CVE-2022-1552)

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

 -- Athos Ribeiro <email address hidden> Tue, 17 May 2022 10:58:43 -0300

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #1973627).

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

    + However, if you have any GiST indexes on columns of type ltree (supplied
      by the contrib/ltree extension), you should re-index them after updating.
      See the upstream changelog linked below for further information.

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

    + Confine additional operations within "security restricted operation"
      sandboxes (Sergey Shinderuk, Noah Misch).

      Autovacuum, CLUSTER, CREATE INDEX, REINDEX, REFRESH MATERIALIZED VIEW,
      and pg_amcheck activated the "security restricted operation" protection
      mechanism too late, or even not at all in some code paths. A user having
      permission to create non-temporary objects within a database could
      define an object that would execute arbitrary SQL code with superuser
      permissions the next time that autovacuum processed the object, or that
      some superuser ran one of the affected commands against it.

      The PostgreSQL Project thanks Alexander Lakhin for reporting this
      problem.
      (CVE-2022-1552)

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

  * d/p/llvm14-support.patch: drop patch applied upstream.

 -- Athos Ribeiro <email address hidden> Mon, 16 May 2022 16:17:01 -0300

[Launchpad Janitor (janitor)]

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

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

  * New upstream version (LP: #1973627)

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

    + However, if you are upgrading from a version earlier than 12.10,
      see those release notes as well.

    + Confine additional operations within "security restricted operation"
      sandboxes (Sergey Shinderuk, Noah Misch).

      Autovacuum, CLUSTER, CREATE INDEX, REINDEX, REFRESH MATERIALIZED VIEW,
      and pg_amcheck activated the "security restricted operation" protection
      mechanism too late, or even not at all in some code paths. A user having
      permission to create non-temporary objects within a database could
      define an object that would execute arbitrary SQL code with superuser
      permissions the next time that autovacuum processed the object, or that
      some superuser ran one of the affected commands against it.

      The PostgreSQL Project thanks Alexander Lakhin for reporting this
      problem.
      (CVE-2022-1552)

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

 -- Sergio Durigan Junior <email address hidden> Tue, 17 May 2022 22:10:51 -0400