On 11/30/17 21:11, Michael Paquier wrote:
> OK, here is a reworked version with the following changes:
> - renamed saslchannelbinding to scramchannelbinding, with a default
> set to tls-unique.
> - An empty value of scramchannelbinding allows client to not use
> channel binding, or in short use use SCRAM-SHA-256 and cbind-flag set
> to 'n'.
>
> While reviewing the code, I have found something a bit disturbing with
> the header definitions: the libpq frontend code includes scram.h,
> which references backend-side routines. So I think that the definition
> of the SCRAM mechanisms as well as the channel binding types should be
> moved to scram-common.h. This cleanup is included in 0001.
I have committed 0001 and 0002 (renaming to scram_channel_binding).
The 0003 patch looks mostly fine as well. The only concern I have is
that the way it is set up now, we make the server compute the channel
binding data for both tls-unique and tls-server-end-point, even though
we only end up using one. This might need some restructuring so that we
only get the data we need once we have learned which channel binding
type the client requested.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services