> On 22 Jan 2018, at 08:29, Michael Paquier <michael.paquier@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
