Andres Freund <andres@anarazel.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
tosee because it's the most intricate part of these changes. (I'm reasonably confident that the code becomes simpler
withoutit, 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
