Re: [PATCH v3] GSSAPI encryption support

Andreas, can you please weigh in here since your voice is important to
this process?

Robbie Harwood <rharwood(at)redhat(dot)com> writes:

> Andres Freund <andres(at)anarazel(dot)de> writes:
>
>> On 2015-10-22 16:47:09 +0900, Michael Paquier wrote:
>>> Hm, and that's why you chose this way of going. My main concern about
>>> this patch is that it adds on top of the existing Postgres protocol a
>>> layer to encrypt and decrypt the messages between server and client
>>> based on GSSAPI. All messages transmitted between client and server
>>> are changed to 'g' messages on the fly and switched back to their
>>> original state at reception. This is symbolized by the four routines
>>> you added in the patch in this purpose, two for frontend and two for
>>> backend, each one for encryption and decryption. I may be wrong of
>>> course, but it seems to me that this approach will not survive
>>> committer-level screening because of the fact that context-level
>>> things invade higher level protocol messages.
>>
>> Agreed. At least one committer here indeed thinks this approach is not
>> acceptable (and I've said so upthread).
>
> Okay, I'll make some changes. Before I do, though, since this is not
> the approach I came up with, can you explicitly state what you're
> looking for here? It subjectively seems that I'm getting a lot of
> feedback of "this feels wrong" without suggestion for improvement.
>
> To be clear, what I need to know is:
>
> - What changes do you want to see in the wire protocol? (And how will
> fallback be supported if that's affected?)
>
> - Since this seems to be an important sticking point, what files am I
> encouraged to change (or prohibited from changing)? (Fallback makes
> this complex.)
>
> - I've been assuming that we care about fallback, but I'd like to be
> told that it's something postgres actually wants to see because it's
> the most intricate part of these changes. (I'm reasonably confident
> that the code becomes simpler without it, and I myself have no use for
> it.)
>
> If I understand what you're asking for (and the above is intended to be
> sure that I will), this will not be a trivial rework, so I want to be
> really sure before doing that because writing this code a third time is
> something I don't relish.
>
> Thanks,
> --Robbie