New upstream microreleases 10.17 12.7 13.3

PPA builds and tests ran:
Bionic - https://bileto.ubuntu.com/#/ticket/4555
Focal - https://bileto.ubuntu.com/#/ticket/4556
Groovy - https://bileto.ubuntu.com/#/ticket/4557
Hirsute - https://bileto.ubuntu.com/#/ticket/4558

Of those Focal-Hirsute look all good to me.

Bionic is a bit problematic with reproducible issues (only on armhf) that have to be checked in detail. Affected tests are:
- postgis
- postgresql-10
- psqlodbc
- slony1-2

Of the above
- postgis
- psqlodbc
- slony1-2

All fail on:
/usr/bin/pg_virtualenv: line 174: /tmp/pgpassword.o2j3Z4: Permission denied

- postgresql-10

# Failed test 'default log is not used'
# at ./t/020_create_sql_remove.t line 133.
not ok 31 - default log is not used
...
not ok 36 - default log is not used

Neither of those seem obviously arch-dependent to only occur on armhf.
I'll have to go to canonistack with that.

FYI postgresql-10 resolved, it was just flaky after all.

Manual checks on armhf in canonistack

Test: postgis (but slony and psqlodbc have the exact same error)
1. installing dependencies (works as in the autopkgtest)
2. check pg_buildext supported-versions
  => 10
  ok that works and is as expected
3. + pg_virtualenv -v 10 sh -e
/usr/bin/pg_virtualenv: line 174: /tmp/pgpassword.gJU4VI: Permission denied

So the virtualenv call has the issue as it was expected from the permission error already.
^^ This happens as-is without anything from my PPAs or proposed.

This file is generated like:
    PWFILE=$(mktemp -t pgpassword.XXXXXX)
    chown postgres:postgres "$PWFILE"
And at the time of the error it is like:
-rw------- 1 postgres postgres 0 May 31 13:35 /tmp/pgpassword.fCpFSb

Since the test runs as root that access fails.
This isn't a problem with the new postgresql that we have prepared.
This was later made more resilent in https://salsa.debian.org/postgresql/postgresql-common/-/commit/aa4829c899a3cf7ea6c90990d989dd57d2a63857

As soon as that permission issue is fixed (in the manual test) then it runs fine.

All that seems to make sense, the one puzzling part that remains why has this ever worked https://autopkgtest.ubuntu.com/packages/p/postgis/bionic/armhf ?

The permissions set by mktemp in src:coreutils are 0600 (file) and 0700 (dir) for ages.
And there as no change to the package in bionic since 18 Jan 2018.

I've also ran the slony and psqlodbc tests - both worked fine.
So we can release these builds but need to consider backporting the password fix.
=> that will be covered via an MP to the test hints

MP for the test hints of what I found in Bionic
https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/403517

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

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

  * New upstream version (LP: #1928773).

    + Prevent integer overflows in array subscripting calculations (Tom Lane)

      The array code previously did not complain about cases where an array's
      lower bound plus length overflows an integer. This resulted in later
      entries in the array becoming inaccessible (since their subscripts could
      not be written as integers), but more importantly it confused subsequent
      assignment operations. This could lead to memory overwrites, with
      ensuing crashes or unwanted data modifications. (CVE-2021-32027)

    + Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
      target lists (Tom Lane)

      If the UPDATE list contains any multi-column sub-selects (which give
      rise to junk columns in addition to the results proper), the UPDATE path
      would end up storing tuples that include the values of the extra junk
      columns. That's fairly harmless in the short run, but if new columns are
      added to the table then the values would become accessible, possibly
      leading to malfunctions if they don't match the datatypes of the added
      columns.

      In addition, in versions supporting cross-partition updates, a
      cross-partition update triggered by such a case had the reverse problem:
      the junk columns were removed from the target list, typically causing an
      immediate crash due to malfunction of the multi-column sub-select
      mechanism. (CVE-2021-32028)

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:17:37 +0200

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

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

  * New upstream version (LP: #1928773).

    + Prevent integer overflows in array subscripting calculations (Tom Lane)

      The array code previously did not complain about cases where an array's
      lower bound plus length overflows an integer. This resulted in later
      entries in the array becoming inaccessible (since their subscripts could
      not be written as integers), but more importantly it confused subsequent
      assignment operations. This could lead to memory overwrites, with
      ensuing crashes or unwanted data modifications. (CVE-2021-32027)

    + Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
      target lists (Tom Lane)

      If the UPDATE list contains any multi-column sub-selects (which give
      rise to junk columns in addition to the results proper), the UPDATE path
      would end up storing tuples that include the values of the extra junk
      columns. That's fairly harmless in the short run, but if new columns are
      added to the table then the values would become accessible, possibly
      leading to malfunctions if they don't match the datatypes of the added
      columns.

      In addition, in versions supporting cross-partition updates, a
      cross-partition update triggered by such a case had the reverse problem:
      the junk columns were removed from the target list, typically causing an
      immediate crash due to malfunction of the multi-column sub-select
      mechanism. (CVE-2021-32028)

    + Fix possibly-incorrect computation of UPDATE ... RETURNING outputs for
      joined cross-partition updates (Amit Langote, Etsuro Fujita)

      If an UPDATE for a partitioned table caused a row to be moved to another
      partition with a physically different row type (for example, one with a
      different set of dropped columns), computation of RETURNING results for
      that row could produce errors or wrong answers. No error is observed
      unless the UPDATE involves other tables being joined to the target
      table. (CVE-2021-32029)

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:13:14 +0200

This bug was fixed in the package postgresql-13 - 13.3-0ubuntu0.21.04.1

---------------
postgresql-13 (13.3-0ubuntu0.21.04.1) hirsute-security; urgency=medium

  * New upstream version (LP: #1928773).

    + Prevent integer overflows in array subscripting calculations (Tom Lane)

      The array code previously did not complain about cases where an array's
      lower bound plus length overflows an integer. This resulted in later
      entries in the array becoming inaccessible (since their subscripts could
      not be written as integers), but more importantly it confused subsequent
      assignment operations. This could lead to memory overwrites, with
      ensuing crashes or unwanted data modifications. (CVE-2021-32027)

    + Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
      target lists (Tom Lane)

      If the UPDATE list contains any multi-column sub-selects (which give
      rise to junk columns in addition to the results proper), the UPDATE path
      would end up storing tuples that include the values of the extra junk
      columns. That's fairly harmless in the short run, but if new columns are
      added to the table then the values would become accessible, possibly
      leading to malfunctions if they don't match the datatypes of the added
      columns.

      In addition, in versions supporting cross-partition updates, a
      cross-partition update triggered by such a case had the reverse problem:
      the junk columns were removed from the target list, typically causing an
      immediate crash due to malfunction of the multi-column sub-select
      mechanism. (CVE-2021-32028)

    + Fix possibly-incorrect computation of UPDATE ... RETURNING outputs for
      joined cross-partition updates (Amit Langote, Etsuro Fujita)

      If an UPDATE for a partitioned table caused a row to be moved to another
      partition with a physically different row type (for example, one with a
      different set of dropped columns), computation of RETURNING results for
      that row could produce errors or wrong answers. No error is observed
      unless the UPDATE involves other tables being joined to the target
      table. (CVE-2021-32029)

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:06:38 +0200

This bug was fixed in the package postgresql-12 - 12.7-0ubuntu0.20.10.1

---------------
postgresql-12 (12.7-0ubuntu0.20.10.1) groovy-security; urgency=medium

  * New upstream version (LP: #1928773).

    + Prevent integer overflows in array subscripting calculations (Tom Lane)

      The array code previously did not complain about cases where an array's
      lower bound plus length overflows an integer. This resulted in later
      entries in the array becoming inaccessible (since their subscripts could
      not be written as integers), but more importantly it confused subsequent
      assignment operations. This could lead to memory overwrites, with
      ensuing crashes or unwanted data modifications. (CVE-2021-32027)

    + Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
      target lists (Tom Lane)

      If the UPDATE list contains any multi-column sub-selects (which give
      rise to junk columns in addition to the results proper), the UPDATE path
      would end up storing tuples that include the values of the extra junk
      columns. That's fairly harmless in the short run, but if new columns are
      added to the table then the values would become accessible, possibly
      leading to malfunctions if they don't match the datatypes of the added
      columns.

      In addition, in versions supporting cross-partition updates, a
      cross-partition update triggered by such a case had the reverse problem:
      the junk columns were removed from the target list, typically causing an
      immediate crash due to malfunction of the multi-column sub-select
      mechanism. (CVE-2021-32028)

    + Fix possibly-incorrect computation of UPDATE ... RETURNING outputs for
      joined cross-partition updates (Amit Langote, Etsuro Fujita)

      If an UPDATE for a partitioned table caused a row to be moved to another
      partition with a physically different row type (for example, one with a
      different set of dropped columns), computation of RETURNING results for
      that row could produce errors or wrong answers. No error is observed
      unless the UPDATE involves other tables being joined to the target
      table. (CVE-2021-32029)

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

 -- Christian Ehrhardt <email address hidden> Tue, 18 May 2021 12:13:14 +0200