Re: libpq support for NegotiateProtocolVersion
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Jacob Champion <jchampion@timescale.com>,
Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-11T15:13:28Z
Lists: pgsql-hackers
On 09.11.22 00:08, Jacob Champion wrote: > On 11/8/22 00:40, Peter Eisentraut wrote: >> On 02.11.22 20:02, Jacob Champion wrote: >>> This new code path doesn't go through the message length checks that are >>> done for the 'R' and 'E' cases, and pqGetNegotiateProtocolVersion3() >>> doesn't take the message length to know where to stop anyway, so a >>> misbehaving server can chew up client resources. >> >> Fixed in new patch. > > pqGetNegotiateProtocolVersion3() is still ignoring the message length, > though; it won't necessarily stop at the message boundary. I don't follow. The calls to pqGetInt(), pqGets(), etc. check the message length. Do you have something else in mind? Can you give an example or existing code? >>> I think the documentation on NegotiateProtocolVersion (not introduced in >>> this patch) is misleading/wrong; it says that the version number sent >>> back is the "newest minor protocol version supported by the server for >>> the major protocol version requested by the client" which doesn't seem >>> to match the actual usage seen here. >> >> I don't follow. If libpq sends a protocol version of 3.1, then the >> server responds by saying it supports only 3.0. What are you seeing? > > I see what you've described on my end, too. The sentence I quoted seemed > to imply that the server should respond with only the minor version (the > least significant 16 bits). I think it should probably just say "newest > protocol version" in the docs. Ok, I see the distinction.
Commits
-
libpq: Handle NegotiateProtocolVersion message
- bbf9c282ce92 16.0 landed
-
libpq: Correct processing of startup response messages
- dce92e59b1a9 16.0 landed