| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | cary huang <hcary328(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Setting min/max TLS protocol in clientside libpq |
| Date: | 2020-01-14 14:34:15 |
| Message-ID: | B66155BC-671D-4955-8B00-D584BB86F532@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 11 Jan 2020, at 03:49, Michael Paquier <michael(at)paquier(dot)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 | Content-Type | Size |
|---|---|---|
| libpq_minmaxproto_v3.patch | application/octet-stream | 19.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Verite | 2020-01-14 14:37:21 | Re: Making psql error out on output failures |
| Previous Message | Konstantin Knizhnik | 2020-01-14 14:18:31 | Create/alter policy and exclusive table lock |