From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(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:01:38 |
Message-ID: | CA+TgmoaNFFeyy8x7KKPUxn3VS8MixM7Y1kFjmcbYBqLCfoYjLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 20, 2024 at 12:49 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> ...and my response was that, no, the proposal doesn't seem to be
> requiring that authentication take place before compression is done.
> (As evidenced by your email. :D) If the claim is that there are no
> security problems with letting unauthenticated clients force
> decompression, then I can try to poke holes in that;
I would prefer this approach, so I suggest trying to poke holes here
first. If you find big enough holes then...
> or if the claim
> is that we don't need to worry about that at all because we'll wait
> until after authentication, then I can poke holes in that too. My
> request is just that we choose one.
...we can fall back to this and you can try to poke holes here.
I really hope that you can't poke big enough holes to kill the feature
entirely, though. Because that sounds sad.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-05-20 17:09:46 | Re: pg_combinebackup does not detect missing files |
Previous Message | Alexander Lakhin | 2024-05-20 17:00:00 | Cleaning up perl code |