Message-ID: <fb35aa7f57fd93f8e2c743101a6f6a64fb751d0c.camel@cybertec.at>
Subject: Re: Decision by Monday: PQescapeString() vs. encoding violation
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Noah Misch <noah@leadboat.com>, pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, pgsql@j-davis.com, tgl@sss.pgh.pa.us
Date: Sat, 15 Feb 2025 09:33:21 +0100
In-Reply-To: <20250215012712.45@rfd.leadboat.com>
References: <20250215012712.45@rfd.leadboat.com>
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) 
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/fb35aa7f57fd93f8e2c743101a6f6a64fb751d0c.camel%40cybertec.at>
Precedence: bulk

On Fri, 2025-02-14 at 17:27 -0800, Noah Misch wrote:
> Commit 5dc1e42b4fa6a4434afa7d7cdcf0291351a7b873 for this week's CVE-2025-=
1094
> changed how PQescapeString()[1] reacts to input that is not valid in the
> client encoding.=C2=A0 Before that commit, the function would ignore enco=
ding
> problems except at the end of the string.=C2=A0 Now, it replaces the bad =
sequence
> up to the length implied by the first byte.=C2=A0 For example, if UTF8 in=
put has
> 0xc2 followed by an ASCII byte, the function removes both bytes.
>=20
> Jeff Davis reported to the security team that
> http://www.unicode.org/reports/tr36/#Ill-Formed_Subsequences=C2=A0forbids=
 something
> like this, saying a UTF-8 converter "must not consume the [second byte] i=
f it
> continues".=C2=A0 (That's my summary, not his.=C2=A0 He might reply to ad=
d color here.)
> While PQescapeString() is not a UTF-8 converter, that standard still felt=
 to
> multiple security team members like a decent argument for removing only t=
he
> invalid 0xc2, not the byte following it.
>=20
> Security team members disagreed on whether next week's releases are the l=
ast
> reasonable chance to change this, or whether changing it in e.g. May woul=
d be
> reasonable.=C2=A0 If applications make changes to cope with the new behav=
ior, that
> could be an argument against further change.
>=20
> Question for all: would you switch to the "remove fewer bytes" behavior i=
n
> next week's releases, switch later, or switch never?=C2=A0 Why so?=C2=A0 =
Please answer
> in the next 24hr if possible, given the little time until we wrap next we=
ek's
> releases on Monday.=C2=A0 I regret the late notice.

I don't have a very strong opinion, but I'm leaning towards removing fewer =
bytes.

My reasoning is that most encoding confusion comes from Microsoft's tenacio=
us
clinging to non-Unicode encodings, and in my part of the world single-byte
encodings are prevalent on Windows systems.  Removing more bytes from the s=
tring
would mean removing more characters, which would mutilate the string more t=
han
necessary.

About when to make that change: having fewer backward-incompatible behavior
changes is desirable, which would speak for doing it now.  If you feel that=
 the
short time frame is long enough for you to write good, reliable code, great=
.
If you feel that it would be better for the quality of the code to have mor=
e
time, take the time.  Better one more subtle change than another security b=
ug.

Yours,
Laurenz Albe

--=20

*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den=20
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat=
=20
dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte,=20
dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder=
=20
Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich=
=20
in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

*CONFIDENTIALITY NOTICE & DISCLAIMER
*This message and any attachment are=20
confidential and may be privileged or otherwise protected from disclosure=
=20
and solely for the use of the person(s) or entity to whom it is intended.=
=20
If you have received this message in error and are not the intended=20
recipient, please notify the sender immediately and delete this message and=
=20
any attachment from your system. If you are not the intended recipient, be=
=20
advised that any use of this message is prohibited and may be unlawful, and=
=20
you must not copy this message or attachment or disclose the contents to=20
any other person.