Re: Add support to TLS 1.3 cipher suites and curves lists

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Erica Zhang <ericazhangy2021@qq.com>, Andres Freund <andres@anarazel.de>, Jelte Fennema-Nio <postgres@jeltef.nl>, Jacob Champion <jacob.champion@enterprisedb.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-12T20:03:33Z
Lists: pgsql-hackers

Attachments

> On 11 Jul 2024, at 23:16, Peter Eisentraut <peter@eisentraut.org> wrote:

> It would be worth checking the discussion at <https://www.postgresql.org/message-id/flat/79692bf9-17d3-41e6-b9c9-fc8c3944222a@eisentraut.org> about strtok()/strtok_r() issues.  First, for list parsing, it sometimes gives the wrong semantics, which I think might apply here.  Maybe it's worth comparing this with the semantics that OpenSSL provides natively. And second, strtok_r() is not available on Windows without the workaround provided in that thread.
> 
> I'm doubtful that it's worth replicating all this list parsing logic instead of just letting OpenSSL do it.  This is a very marginal feature after all.

The original author added the string parsing in order to provide a good error
message in case of an error in the list, and since that seemed like a nice idea
I kept in my review revision.  With what you said above I agree it's not worth
the extra complexity it brings so the attached revision removes it.

--
Daniel Gustafsson

Commits

  1. Handle alphanumeric characters in matching GUC names

  2. Only perform pg_strong_random init when required