We need the Pacific/Enderbury timezone in tests. Depend on
tzdata-legacy, or tzdata before 2023c-8.

Patching configure.ac is enough

Thanks! (Closes: #1059170)

Clang hasn't built there yet and it's also disabled on hurd-i386

Tarballs won't have these files anymore, they are built from git.

  + Ensure cached plans are marked as dependent on the calling role when RLS
    applies to a non-top-level table reference (Nathan Bossart)
    If a CTE, subquery, sublink, security invoker view, or coercion
    projection in a query references a table with row-level security
    policies, we neglected to mark the resulting plan as potentially
    dependent on which role is executing it.  This could lead to later query
    executions in the same session using the wrong plan, and then returning
    or hiding rows that should have been hidden or returned instead.
    The PostgreSQL Project thanks Wolfgang Walther for reporting this
    problem. (CVE-2024-10976)
  + Make libpq discard error messages received during SSL or GSS protocol
    negotiation (Jacob Champion)
    An error message received before encryption negotiation is completed
    might have been injected by a man-in-the-middle, rather than being real
    server output.  Reporting it opens the door to various security hazards;
    for example, the message might spoof a query result that a careless user
    could mistake for correct output.  The best answer seems to be to
    discard such data and rely only on libpq's own report of the connection
    failure.
    The PostgreSQL Project thanks Jacob Champion for reporting this problem.
    (CVE-2024-10977)
  + Fix unintended interactions between SET SESSION AUTHORIZATION and SET
    ROLE (Tom Lane)
    The SQL standard mandates that SET SESSION AUTHORIZATION have a
    side-effect of doing SET ROLE NONE.  Our implementation of that was
    flawed, creating more interaction between the two settings than
    intended. Notably, rolling back a transaction that had done SET SESSION
    AUTHORIZATION would revert ROLE to NONE even if that had not been the
    previous state, so that the effective user ID might now be different
    from what it had been before the transaction.  Transiently setting
    session_authorization in a function SET clause had a similar effect. A
    related bug was that if a parallel worker inspected
    current_setting('role'), it saw none even when it should see something
    else.
    The PostgreSQL Project thanks Tom Lane for reporting this problem.
    (CVE-2024-10978)
  + Prevent trusted PL/Perl code from changing environment variables
    (Andrew Dunstan, Noah Misch)
    The ability to manipulate process environment variables such as PATH
    gives an attacker opportunities to execute arbitrary code.  Therefore,
    trusted PLs must not offer the ability to do that.  To fix plperl,
    replace %ENV with a tied hash that rejects any modification attempt with
    a warning. Untrusted plperlu retains the ability to change the
    environment.
    The PostgreSQL Project thanks Coby Abrams for reporting this problem.
    (CVE-2024-10979)

  + Repair ABI break for extensions that work with struct ResultRelInfo
    Last week's minor releases unintentionally broke binary compatibility
    with timescaledb and several other extensions.  Restore the affected
    structure to its previous size, so that such extensions need not be
    rebuilt.
  + Restore functionality of ALTER {ROLE|DATABASE} SET role
    The fix for CVE-2024-10978 accidentally caused settings for role to not
    be applied if they come from non-interactive sources, including previous
    ALTER {ROLE|DATABASE} commands and the PGOPTIONS environment variable.

  + Harden PQescapeString and allied functions against invalidly-encoded
    input strings (Andres Freund, Noah Misch)
    Data-quoting functions supplied by libpq now fully check the encoding
    validity of their input.  If invalid characters are detected, they
    report an error if possible.  For the ones that lack an error return
    convention, the output string is adjusted to ensure that the server will
    report invalid encoding and no intervening processing will be fooled by
    bytes that might happen to match single quote, backslash, etc.
    The purpose of this change is to guard against SQL-injection attacks
    that are possible if one of these functions is used to quote crafted
    input.  There is no hazard when the resulting string is sent directly to
    a PostgreSQL server (which would check its encoding anyway), but there
    is a risk when it is passed through psql or other client-side code.
    Historically such code has not carefully vetted encoding, and in many
    cases it's not clear what it should do if it did detect such a problem.
    This fix is effective only if the data-quoting function, the server, and
    any intermediate processing agree on the character encoding that's being
    used.  Applications that insert untrusted input into SQL commands should
    take special care to ensure that that's true.
    Applications and drivers that quote untrusted input without using these
    libpq functions may be at risk of similar problems.  They should first
    confirm the data is valid in the encoding expected by the server.
    The PostgreSQL Project thanks Stephen Fewer for reporting this problem.
    (CVE-2025-1094)

  + Improve behavior of libpq's quoting functions (Andres Freund, Tom Lane)
    The changes made for CVE-2025-1094 had one serious oversight:
    PQescapeLiteral() and PQescapeIdentifier() failed to honor their string
    length parameter, instead always reading to the input string's trailing
    null.  This resulted in including unwanted text in the output, if the
    caller intended to truncate the string via the length parameter.  With
    very bad luck it could cause a crash due to reading off the end of
    memory.
    In addition, modify all these quoting functions so that when invalid
    encoding is detected, an invalid sequence is substituted for just the
    first byte of the presumed character, not all of it.  This reduces the
    risk of problems if a calling application performs additional processing
    on the quoted string.

libpq5: Recommend ca-certificates to support SSL certificate validation using the sslrootcert=system connection option.

Suggested by George MacKerron, thanks!

  + Avoid one-byte buffer overread when examining invalidly-encoded strings
    that are claimed to be in GB18030 encoding (Noah Misch, Andres Freund)
    While unlikely, a SIGSEGV crash could occur if an incomplete multibyte
    character appeared at the end of memory.  This was possible both in the
    server and in libpq-using applications. (CVE-2025-4207)

  + Tighten security checks in planner estimation functions (Dean Rasheed)
    The fix for CVE-2017-7484, plus followup fixes, intended to prevent
    leaky functions from being applied to statistics data for columns that
    the calling user does not have permission to read.  Two gaps in that
    protection have been found.  One gap applies to partitioning and
    inheritance hierarchies where RLS policies on the tables should restrict
    access to statistics data, but did not.
    The other gap applies to cases where the query accesses a table via a
    view, and the view owner has permissions to read the underlying table
    but the calling user does not have permissions on the view. The view
    owner's permissions satisfied the security checks, and the leaky
    function would get applied to the underlying table's statistics before
    we check the calling user's permissions on the view.  This has been
    fixed by making security checks on views occur at the start of planning.
    That might cause permissions failures to occur earlier than before.
    The PostgreSQL Project thanks Dean Rasheed for reporting this problem.
    (CVE-2025-8713)
  + Prevent pg_dump scripts from being used to attack the user running the
    restore (Nathan Bossart)
    Since dump/restore operations typically involve running SQL commands as
    superuser, the target database installation must trust the source
    server.  However, it does not follow that the operating system user who
    executes psql to perform the restore should have to trust the source
    server.  The risk here is that an attacker who has gained
    superuser-level control over the source server might be able to cause it
    to emit text that would be interpreted as psql meta-commands. That would
    provide shell-level access to the restoring user's own account,
    independently of access to the target database.
    To provide a positive guarantee that this can't happen, extend psql with
    a \restrict command that prevents execution of further meta-commands,
    and teach pg_dump to issue that before any data coming from the source
    server.
    The PostgreSQL Project thanks Martin Rakhmanov, Matthieu Denais, and
    RyotaK for reporting this problem. (CVE-2025-8714)
  + Convert newlines to spaces in names included in comments in pg_dump
    output (Noah Misch)
    Object names containing newlines offered the ability to inject arbitrary
    SQL commands into the output script.  (Without the preceding fix,
    injection of psql meta-commands would also be possible this way.)
    CVE-2012-0868 fixed this class of problem at the time, but later work
    reintroduced several cases.
    The PostgreSQL Project thanks Noah Misch for reporting this problem.
    (CVE-2025-8715)

We dropped the trailing 0 from the Debian release number in pgdgNN tags;
snapshot builds need a version bump.

  + Check for CREATE privileges on the schema in CREATE STATISTICS
    (Jelte Fennema-Nio)
    This omission allowed table owners to create statistics in any schema,
    potentially leading to unexpected naming conflicts.
    The PostgreSQL Project thanks Jelte Fennema-Nio for reporting this
    problem. (CVE-2025-12817)
  + Avoid integer overflow in allocation-size calculations within libpq
    (Jacob Champion)
    Several places in libpq were not sufficiently careful about computing
    the required size of a memory allocation.  Sufficiently large inputs
    could cause integer overflow, resulting in an undersized buffer, which
    would then lead to writing past the end of the buffer.
    The PostgreSQL Project thanks Aleksey Solovev of Positive Technologies
    for reporting this problem. (CVE-2025-12818)