From: Stephen Frost <sfrost@snowman.net>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Daniil Zakhlystov <usernamedt@yandex-team.ru>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: libpq compression (part 2)
Date: Fri, 7 Jan 2022 15:56:39 -0500
Message-ID: <20220107205638.GP15820@tamriel.snowman.net> (raw)
In-Reply-To: <20220107192110.GG14051@telsasoft.com>
References: <ABAA09C6-BB95-47A5-890D-90353533F9AC@yandex-team.ru>
<20220101172504.GW24477@telsasoft.com>
<YdiKaL/AhNV9OtvK@momjian.us>
<20220107192110.GG14051@telsasoft.com>
Greetings,
* Justin Pryzby (pryzby@telsasoft.com) wrote:
> On Fri, Jan 07, 2022 at 01:46:00PM -0500, Bruce Momjian wrote:
> > On Sat, Jan 1, 2022 at 11:25:05AM -0600, Justin Pryzby wrote:
> > > Thanks for working on this. The patch looks to be in good shape - I hope more
> > > people will help to review and test it. I took the liberty of creating a new
> > > CF entry. http://cfbot.cputube.org/daniil-zakhlystov.html
> > >
> > > +zpq_should_compress(ZpqStream * zpq, char msg_type, uint32 msg_len)
> > > +{
> > > + return zpq_choose_compressor(zpq, msg_type, msg_len) == -1;
> > >
> > > I think this is backwards , and should say != -1 ?
> > >
> > > As written, the server GUC libpq_compression defaults to "on", and the client
> > > doesn't request compression. I think the server GUC should default to off.
> > > I failed to convince Kontantin about this last year. The reason is that 1)
> > > it's a new feature; 2) with security implications. An admin should need to
> > > "opt in" to this. I still wonder if this should be controlled by a new "TYPE"
> > > in pg_hba (rather than a GUC); that would make it exclusive of SSL.
> >
> > I assume this compression happens before it is encrypted for TLS
> > transport. Second, compression was removed from TLS because there were
> > too many ways for HTTP to weaken encryption. I assume the Postgres wire
> > protocol doesn't have similar exploit possibilities.
>
> It's discussed in last year's thread. The thinking is that there tends to be
> *fewer* exploitable opportunities between application->DB than between
> browser->app.
Yes, this was discussed previously and addressed.
> But it's still a known concern, and should default to off - as I said.
I'm not entirely convinced of this but also am happy enough as long as
the capability exists, no matter if it's off or on by default.
> That's also why I wondered if compression should be controlled by pg_hba,
> rather than a GUC. To require/allow an DBA to opt-in to it for specific hosts.
> Or to make it exclusive of ssl. We could choose to not suppose that case at
> all, or (depending on the implement) refuse that combination of layers.
I'm definitely against us deciding that we know better than admins if
this is an acceptable trade-off in their environment, or not. Letting
users/admins control it is fine, but I don't feel we should forbid it.
As for the details of how we allow control over it, I suppose there's a
number of options. Having it in the HBA doesn't seem terrible, though I
suspect most will just want to enable it across the board and having to
have "compression=allowed" or whatever added to every hba line seems
likely to be annoying. Maybe a global GUC and then allow the hba to
override?
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, pryzby@telsasoft.com, bruce@momjian.us, usernamedt@yandex-team.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: libpq compression (part 2)
In-Reply-To: <20220107205638.GP15820@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox