Re: Setting min/max TLS protocol in clientside libpq - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Setting min/max TLS protocol in clientside libpq
Date
Msg-id B66155BC-671D-4955-8B00-D584BB86F532@yesql.se
Whole thread Raw
In response to Re: Setting min/max TLS protocol in clientside libpq  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Setting min/max TLS protocol in clientside libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On 11 Jan 2020, at 03:49, Michael Paquier <michael@paquier.xyz> wrote:

> Hmmmmeuh.  It would be perfect to rely only on OpenSSL for that part
> to bring some sanity, and compare the results fetched from the SSL
> context so as we don't have to worry about special cases in with the
> GUC reload if the parameter is not set, or the parameter value is not
> supported.

I'm not convinced about this, but since there is a thread opened for discussing
the range check let's take it over there.

> Daniel, are you planning to start a new thread?

I was going to, but you beat me to it =)

>> One thing I noticed when looking at it is that we now have sha2_openssl.c and
>> openssl_protocol.c in src/common.  For easier visual grouping of OpenSSL
>> functionality, it makes sense to me to rename sha2_openssl.c to openssl_sha2.c,
>> but that might just be pointless churn.
>
> Databases like consistency, and so do I, so no issues from me to do a
> rename of the sha2.c file.  That makes sense with the addition of the
> new file.

Done in the attached v3.

cheers ./daniel


Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Create/alter policy and exclusive table lock
Next
From: "Daniel Verite"
Date:
Subject: Re: Making psql error out on output failures