Re: [PATCH v3] GSSAPI encryption support - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH v3] GSSAPI encryption support
Date
Msg-id CAB7nPqQPMz8A2E=fBggsSsnR8ZH6RMDCLvuHQ11Bt3cxmKXeOQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH v3] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
List pgsql-hackers
On Thu, Oct 22, 2015 at 11:36 PM, Robbie Harwood wrote:
> 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?)

Hm. Something essential will be to send the length of the wrapped
gss_buffer_t object to be sent in the first 4 bytes of the message so
as the receiver can know how much it has to unwrap and can perform
sanity checks on what has been received.

> - Since this seems to be an important sticking point, what files am I
>   encouraged to change (or prohibited from changing)?  (Fallback makes
>   this complex.)

If we want to make that stick into Postgres, I think that we are going
to need be_gss_read and be_gss_write in be-secure.c, and pqgss_write
and pqgss_read in fe-secure.c, the use the context initialized at
authentication time to wrap and unwrap messages between the server and
client.

> - 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.)

As a first shot for this patch, I would not mind if there is no
fallback at protocol level, it seems to me that it is challenging
enough to get a solid core feature first. Perhaps others have
different opinions?

> 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.

This makes sense. Let's be sure that we come up with a clear picture
of what to do first.
-- 
Michael



pgsql-hackers by date:

Previous
From: Victor Wagner
Date:
Subject: Patch (3): Implement failover on libpq connect level.
Next
From: Geoff Winkless
Date:
Subject: Re: About BoringSSL, an OpenSSL fork