Re: [PATCH v2] GSSAPI encryption support

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:

> On Fri, Jul 3, 2015 at 3:22 AM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
>
>> Hello -hackers,
>>
>> As previously discussed on this list, I have coded up GSSAPI encryption
>> support. If it is easier for anyone, this code is also available for
>> viewing on my github:
>>
>> https://github.com/postgres/postgres/compare/master...frozencemetery:feature/gssencrypt
>>
>> Fallback support is present in both directions for talking to old client
>> and old servers; GSSAPI encryption is by default auto-upgraded to where
>> available (for compatibility), but both client and server contain
>> settings for requiring it.
>>
>> There are 8 commits in this series; I have tried to err on the side of
>> creating too much separation rather than too little. A patch for each
>> is attached. This is v1 of the series.
>
> I just had a quick look at this patch, and here are some comments:
> + <para>
> + If the client has probed <acronym>GSSAPI</acronym> encryption support
> and
> + the connection is <acronym>GSSAPI</acronym>-authenticated, then after
> the
> + server sends AuthenticationOk, all traffic between the client and
> server
> + will be <acronym>GSSAPI</acronym>-encrypted. Because
> + <acronym>GSSAPI</acronym> does not provide framing,
> + <acronym>GSSAPI</acronym>-encrypted messages are modeled after
> protocol-3
> + messages: the first byte is the caracter g, then four bytes of length,
> and
> + then an encrypted message.
> + </para>
> Message formats should be described in protocol.sgml in the section for
> message formats.
>
> + network. In the <filename>pg_hba.conf</> file, the GSS authenticaion
> + method has a parameter to require encryption; otherwise, connections
> + will be encrypted if available and requiested by the client. On the
> s/authenticaion/authentication
> s/requiested/requested
>
> + Whether to require GSSAPI encryption. Default is off, which causes
> + GSSAPI encryption to be enabled if available and requested for
> + compatability with old clients. It is recommended to set this
> unless
> + old clients are present.
> s/compatability/compatibility

As promised, here's a V2 to address your issues with comments. I
haven't heard back on the issues you found in testing, so no other
changes are present.

This means that only the last patch has changed. For convenience, I
will therefore only provide this new patch. I have also updated the
version available from my github.

Thanks!