postgresql-17 (17.3-1) unstable; urgency=medium * New upstream version 17.3. + 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) + Adjust tests to tzdata 2025a changes. (Closes: #1093414) * B-D on postgresql-common-dev. * Test-depend only our server packages, i.e. allow libpq5 to be newer. -- Christoph Berg Tue, 11 Feb 2025 11:27:41 +0100 postgresql-17 (17.2-1) unstable; urgency=medium * New upstream version 17.2. + 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. -- Christoph Berg Tue, 19 Nov 2024 15:36:12 +0100 postgresql-17 (17.1-1) unstable; urgency=medium * New upstream version 17.1. + 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) * Fix psql -l against 9.2 and 9.3. -- Christoph Berg Tue, 12 Nov 2024 14:27:34 +0100 postgresql-17 (17.0-1) unstable; urgency=medium * First official version. -- Christoph Berg Tue, 24 Sep 2024 15:26:00 +0200 postgresql-17 (17~rc1-1) unstable; urgency=medium * First RC version. -- Christoph Berg Tue, 03 Sep 2024 11:58:30 +0200 postgresql-17 (17~beta3-1) experimental; urgency=medium * Third beta version. -- Christoph Berg Wed, 07 Aug 2024 16:16:02 +0200 postgresql-17 (17~beta2-1) experimental; urgency=medium * Restrict systemtap-sdt-dev B-D to linux-any. * Add libpq5 symbol PQgetCurrentTimeUSec. -- Christoph Berg Tue, 25 Jun 2024 14:03:14 +0200 postgresql-17 (17~beta1-1) experimental; urgency=medium * First beta version. -- Christoph Berg Wed, 22 May 2024 18:54:56 +0200 postgresql-17 (17~~devel20240509-1) experimental; urgency=medium * New major upstream version 17; packaging based on postgresql-16. -- Christoph Berg Thu, 09 May 2024 18:45:32 +0200