Re: libpq compression (part 3)

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Jacob Burroughs <jburroughs(at)instructure(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq compression (part 3)
Date: 2024-05-20 17:22:55
Message-ID: CAOYmi+n6xQcA664DUDn5HsHTrT2u0hebfNYkgzJ=1J7zSOEx4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

--Jacob

[1] https://datatracker.ietf.org/doc/html/rfc8878#name-security-considerations

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-05-20 17:41:09 Re: soliciting patches to review
Previous Message Robert Haas 2024-05-20 17:11:15 Re: Propagate sanity checks of ProcessUtility() to standard_ProcessUtility()?