Re: Commitfest 2021-11 Patch Triage - Part 2

> On 15 Nov 2021, at 15:32, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Nov 9, 2021 at 9:12 AM Daniel Gustafsson <daniel@yesql.se> wrote:
>> 2773: libpq compression
>> =======================
>> This patch intended to provide libpq connection compression to "replace SSL
>> compression" which was doomed when the patch was written, and have since been
>> removed altogether.  The initial approach didn't get much traction but there
>> was significant discussion and work, which has since fizzled out.  The patch
>> has been updated but there hasn't been meaningful review the past months, the
>> last comments seem to imply there being a fair amount of questionmarks left in
>> here.  Robert, having been very involved in this do you have any thoughts on
>> where we are and where to go (if at all IYO)?
>
> It's been a while since I looked at that patch, and my recollections
> are somewhat fuzzy.

No worries, thanks for sharing!

> However, I think that my main feeling was that the
> quality of the patch didn't seem to be that close to what I felt would
> be required for a commit. I think at that point there were still
> significant questions about the details of the approach as well as
> code-quality and performance concerns. It may have gotten better since
> last I looked.

Context switching into this thread is hard, so it's not clear how much the
patch has moved since you reviewed, or how the current patchset relates to the
earlier one as there seems to have been a shift at a recent(ish) point in time.
The last message (which is unreadable HTML soup in the archives) talks about
implementing lz4 with "Looking forward to post an update soon."

Given the discussions had and the doubts over approach I wonder if the best
course of action with the CF entry in question is to close it, hash out the
what and how on -hackers and reopen a new entry when there is a patch which.
We are not doing ourselves, or the CF process, any favors by moving an entry
along which isn't all that close to committable.

Thoughts (addressing everyone involved/interested)?

> I do agree with the comments from others that there is room to debate
> (1) the usefulness of this and (2) the degree to which it might leave
> us on the hook for security problems that wouldn't be our
> responsibility if we left this up to OpenSSL (or maybe some other SSL
> library, if we ever get pluggability there, which I hope we do). But
> my concerns were more pragmatic than theoretical.

I share you hope here =) However I don't think we'll get much help with
compression from the TLS libraries.  OpenSSL has deprecated transport
compression, NSS never implemented it in the first place, and TLS 1.3 removes
it altogether.  That being said, this is mainly due to protocols where chosen
plaintext attacks are practical/possible.  For our case we, IMHO, should look
more at how OpenSSH and other protocols closer to ours has built compression in
a safe way, to see if we can achieve the level of transport safety we require.

But, there is I think broad concensus that we at least must fully understand
the tradeoffs should we allow compression.

--
Daniel Gustafsson        https://vmware.com/