-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Tue, 11 Feb 2025 11:27:41 +0100
Source: postgresql-15
Binary: postgresql-doc-15
Architecture: all
Version: 15.11-0+deb12u1
Distribution: bookworm
Urgency: medium
Maintainer: all Build Daemon (x86-grnet-02) <buildd_all-x86-grnet-02@buildd.debian.org>
Changed-By: Christoph Berg <myon@debian.org>
Description:
 postgresql-doc-15 - documentation for the PostgreSQL database management system
Changes:
 postgresql-15 (15.11-0+deb12u1) bookworm; urgency=medium
 .
   * New upstream version 15.11.
 .
     + 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)
Checksums-Sha1:
 5f4101b7bfc183b17d90ae7f1ffb97c1935bd214 10425 postgresql-15_15.11-0+deb12u1_all-buildd.buildinfo
 ef6cfbf5cdc4571a11a3c4f61a3ee079f358d638 2064904 postgresql-doc-15_15.11-0+deb12u1_all.deb
Checksums-Sha256:
 ff1a172fed2a695b27380c7d87c6c94600776a6309962eb3cc36718f168755ac 10425 postgresql-15_15.11-0+deb12u1_all-buildd.buildinfo
 3976b544c7175f9778a2be3ad697e36d8c9f4437d91698aa631f1e4db7850394 2064904 postgresql-doc-15_15.11-0+deb12u1_all.deb
Files:
 fb46db5c42e6e078cb9ca91f5c36c5cc 10425 database optional postgresql-15_15.11-0+deb12u1_all-buildd.buildinfo
 52886dc75db76d74a7fb06aea674280c 2064904 doc optional postgresql-doc-15_15.11-0+deb12u1_all.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQsM0t1ygJv2xcx3e4cagXJhOTXsFAmex/xQACgkQ4cagXJhO
TXuOGhAAkLH8ovp8Qs/hnvz3qRdmpogN4IRTYDEGEkWJF+pH3Xdaj/fqizOsBZUm
g8gfZ4b2WbCELpw7BItGAq2Yut7EFZkxbssdkpu+rL5lUqJ0rQcmba5q25Vp2kFA
gqlRjrWbQHWAcZYF5nfkxYPr3V9SJGds5TdxVfW2zwnpqRp1GL/AXtGvf5XW9n+Q
kJD0MYJXRYlHqawYPI+aewbQlJpjXllXhbyzypoR4Gyd66FaceyNVzLrTrFyIETw
zL7FGbdzi+5MrImci0fg1sZxxw3UcWYBzvXyW3DYH1tWL0YkFo4o+CL/rT6plphg
OYdPx2mjXyLY9Vv8hHONtzkQMdaK3+vyP5+U3xARY6wcDU/CCO+xitw/MefE3xHH
qU0PUZHapZyhTglCjsl4o+ScsgaJ2CbQIdxHTPb7I0bpiUkyQ1ChjwFfMU1DldoE
KnONHlAgnsmkuQg+AUzl6pZnu81mJYmHlwKYoeLWOhidd7YM/dqYeVBVeush8xY2
duYRc+/KrAqMhevNgI4LIsX/jUPWCVpWYDqayK/jg9JWdGv47wNELVuMmGaWO19V
rsK4dO1CdrRQ7J5SCTKTZiBdQYCrCSLadHoLjWnA1ERgB5rTk7tHzxgK9sZs49FJ
3RL7epipOpy3hnCKzvsXxF0umK65FFryfhTcJXbKkQcvxAQkueY=
=vgp/
-----END PGP SIGNATURE-----