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
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()? |