Re: Negotiating the SCRAM channel binding type - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Negotiating the SCRAM channel binding type
Date
Msg-id fe08bfe1-80a2-b7d4-56a3-c9f7abeb0bef@iki.fi
Whole thread Raw
In response to Re: Negotiating the SCRAM channel binding type  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Negotiating the SCRAM channel binding type
List pgsql-hackers
On 05/08/18 15:45, Michael Paquier wrote:
> On Sun, Aug 05, 2018 at 03:30:43PM +0300, Heikki Linnakangas wrote:
>> That test just tested that the scram_channel_binding libpq option works, but
>> I removed the option. I know you wanted to keep it as a feature flag, but as
>> discussed earlier, I don't think that'd be useful.
> 
> Sorry for the noise, I missed that there is still the test "Basic SCRAM
> authentication with SSL" so that would be fine.  I would have preferred
> keeping around the negative test so as we don't break SSL connections
> when the client enforced cbind_flag to 'n' as that would be useful when
> adding new SSL implementations as that would avoid manual tests which
> people will most likely forget, but well...

The only negative test there was, was to check for bogus 
scram_channel_binding option, "scram_channel_binding=not-exists". Yeah, 
it would be nice to have some, but this commit didn't really change that 
situation.

I'm hoping that we add a libpq option to actually force channel binding 
soon. That'll make channel binding actually useful to users, but it will 
also make it easier to write tests to check that channel binding is 
actually used or not used, in the right situations.

> You can remove $supports_tls_server_end_point in 002_scram.pl by the
> way.  Should I remove it or perhaps you would prefer to do it?

Ah, good catch. I'll go and remove it, thanks!

- Heikki


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH v18] GSSAPI encryption support
Next
From: Heikki Linnakangas
Date:
Subject: Re: Negotiating the SCRAM channel binding type