> On 22 Jan 2018, at 08:29, Michael Paquier <michael.paqu...@gmail.com> wrote:
> Attached is a patch which is an attempt to make this choice cleaner for > new SSL implementations. As we are (rightly!) calling the APIs to fetch > the channel binding data only when necessary, I think that we need an > extra API for SSL implementations to let the server decide if channel > binding mechanisms should be published or not. There could be multiple > possibilities, like making this API return only a boolean flag. However > I have made a more extensible choice by having each SSL implementation > build a list of supported channel bindings. An extensible API makes more sense than on/off (or one on/off call per binding). Perhaps a way to validate the contents of the list is required though? Or an assertion on the contents to catch errors during testing. Nitpicking: In src/backend/libpq/auth.c:CheckSCRAMAuth(), this comment reads a bit strange: + * Get the list of channel binding types supported by this SSL + * implementation to determine if server should publish -PLUS + * mechanisms or not. Since auth.c isn’t tied to any SSL implementation, shouldn’t it be “supported by the configured SSL implementation” or something along those lines? cheers ./daniel
