From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Handling better supported channel binding types for SSL implementations |
Date: | 2018-01-22 10:07:55 |
Message-ID: | 521AAF1E-FE50-4CF1-AC2B-A2453B361A62@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 22 Jan 2018, at 08:29, Michael Paquier <michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-01-22 10:17:47 | Re: pgsql: Add parallel-aware hash joins. |
Previous Message | Dean Rasheed | 2018-01-22 10:03:56 | Re: stricter MCV tests for uniform distributions (was Re: MCV lists for highly skewed distributions) |