Re: [PATCH v12] GSSAPI encryption support

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robbie Harwood <rharwood@redhat.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2016-04-08T18:24:22Z
Lists: pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Commits

  1. GSSAPI encryption support

  2. Fix typo