Re: Negotiating the SCRAM channel binding type
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Negotiating the SCRAM channel binding type |
| Дата | |
| Msg-id | fe08bfe1-80a2-b7d4-56a3-c9f7abeb0bef@iki.fi обсуждение исходный текст |
| Ответ на | Re: Negotiating the SCRAM channel binding type (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Negotiating the SCRAM channel binding type
|
| Список | 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 по дате отправления: