Re: libpq compression (part 3) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: libpq compression (part 3)
Date
Msg-id CA+TgmoYqD0zFyX_Zot5g12TNQUeMinJf-ri1B3t0GhG7kVXTvw@mail.gmail.com
Whole thread Raw
In response to Re: libpq compression (part 3)  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: libpq compression (part 3)
List pgsql-hackers
On Mon, May 20, 2024 at 1:23 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> On Mon, May 20, 2024 at 10:01 AM Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: soliciting patches to review
Next
From: "Andrey M. Borodin"
Date:
Subject: Re: libpq compression (part 3)