* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Apr 7, 2016 at 10:17 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Robbie Harwood <rharwood@redhat.com> writes:
> >>> Tom Lane <tgl@sss.pgh.pa.us> writes:
> >>>> Wait a second. So the initial connection-request packet is necessarily
> >>>> unencrypted under this scheme?
> >>
> >>> Yes, by necessity. The username must be sent in the clear, even if only
> >>> as part of the GSSAPI handshake (i.e., the GSSAPI username will appear
> >>> in plantext in the GSSAPI blobs which are otherwise encrypted). GSSAPI
> >>> performs authentication before it can start encryption.
> >>
> >> Ugh. I had thought we were putting work into this because it represented
> >> something we could recommend as best practice, but now you're telling me
> >> that it's always going to be inferior to what we have already.
> >
> > It does not seem necessary to have an equivalent of
> > pqsecure_open_client, just some extra handling in fe-connect.c to set
> > up the initial context with a proper message handling... Not that
> > direct anyway. So should the patch be marked as returned with feedback
> > at this stage?
>
> Yeah, I think so. It doesn't seem we have consensus on this, and it's
> too late to be trying to build one now.
Actually, I chatted with Robbie quite a bit over IRC and he's agreed on
reworking this to use the same approach that we use for SSL, but that's
expected to take the better part of a week to do.
While it seems like this particular patch (with myself as committer)
would meet the requirements stated by the RMT for an extension, having
considered it over the past day or so, I don't think we should make it a
policy to allow an extension when it involves a significant rework of
the patch, as is the case here.
Robbie, please be sure to add this to the next commitfest and please
hound me to review it, you know where to find me. :)
Thanks!
Stephen
