Re: libpq compression (part 3)

On Mon, May 20, 2024 at 1:23 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> On Mon, May 20, 2024 at 10:01 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > I really hope that you can't poke big enough holes to kill the feature
> > entirely, though. Because that sounds sad.
>
> Even if there are holes, I don't think the situation's going to be bad
> enough to tank everything; otherwise no one would be able to use
> decompression on the Internet. :D And I expect the authors of the
> newer compression methods to have thought about these things [1].
>
> I hesitate to ask as part of the same email, but what were the plans
> for compression in combination with transport encryption? (Especially
> if you plan to compress the authentication exchange, since mixing your
> LDAP password into the compression context seems like it might be a
> bad idea if you don't want to leak it.)

So, the data would be compressed first, with framing around that, and
then transport encryption would happen afterwards. I don't see how
that would leak your password, but I have a feeling that might be a
sign that I'm about to learn some unpleasant truths.

--
Robert Haas
EDB: http://www.enterprisedb.com