postgresql-17 (17.2-1)
[PTS] [DDPO]
NEW: VCS has unreleased changes: 17.3-1 > 17.2-1
- Git: https://salsa.debian.org/postgresql/postgresql.git -b 17
-
- Branch: 17
- Path: debian/changelog
- Repo size: 13856768
- Browser: https://salsa.debian.org/postgresql/postgresql
- Last scan: 2025-02-11 12:38:06+00
- Next scan: 2025-02-18 19:23:00+00
- Open issues: 2
- Merge requests: 1
- CI pipeline status: failed
- Debian changelog in Git:
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)
* B-D on postgresql-common-dev.
* Test-depend only our server packages, i.e. allow libpq5 to be newer.
-- Christoph Berg <myon@debian.org> Tue, 11 Feb 2025 11:27:41 +0100
- This branch is 3 commits ahead of tag debian/17.2-1
- Git log:
commit e5709f2d9ee8ee4c1be31d35501eeabeb86d0f5e
Author: Christoph Berg <myon@debian.org>
Date: Wed Jan 22 22:26:49 2025 +0100
Test-depend only our server packages, i.e. allow libpq5 to be newer.
commit f4338a0d28cf4541956bddb0f4e444ba9dba81b9
Author: Christoph Berg <myon@debian.org>
Date: Mon Jan 20 21:56:07 2025 +0100
B-D on postgresql-common-dev.
commit d758289958fe7dbdecf2e1bff1812b1196e3aca0
Author: Christoph Berg <myon@debian.org>
Date: Tue Feb 11 11:37:44 2025 +0100
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)