Re: Handling better supported channel binding types for SSL implementations

> 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