Re: libpq compression (part 3)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: libpq compression (part 3)
Дата
Msg-id CA+TgmoYqD0zFyX_Zot5g12TNQUeMinJf-ri1B3t0GhG7kVXTvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: libpq compression (part 3)  (Jacob Champion <jacob.champion@enterprisedb.com>)
Ответы Re: libpq compression (part 3)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: soliciting patches to review
Следующее
От: "Andrey M. Borodin"
Дата:
Сообщение: Re: libpq compression (part 3)