Horton

Re: Request for comment on setting binary format output per session

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Dave Cramer <davecramer@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-29T16:04:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Silence compiler warning introduced in 1edb3b491b

On Wed, 2023-03-29 at 08:17 -0400, Dave Cramer wrote:
> I'm starting to wonder about the utility of the protocol extension
> mechanism? 

I'm starting to agree that the awkwardness around connection poolers is
a problem. If that's the case, I'm wondering if the protocol extensions
will ever be useful.

What I'm worried about with the GUC is that an attacker may be able to
start with a SQL injection attack, and then use the GUC to confuse a
client in a way that further escalates privileges. Is that a reasonable
fear?

A couple ideas to mitigate that concern with the GUC:

1. Fix our own clients, like psql, to check for binary data they can't
process.

2. Communicate (after the patch is committed) with client library
maintainers to see that they behave sanely when they receive binary
data unexpectedly.

3. Require that the binary_formats parameter is set very early, either
during connection startup or right after a DISCARD statement. A bit of
a hack, but may help. Not sure it really solves my security concern
because they'd just need to modify their SQL injection to also include
a DISCARD statement.

Regards,
	Jeff Davis