On Wed, Dec 11, 2024 at 12:47:01PM -0500, Tom Lane wrote:
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
>> On Wed, Dec 11, 2024 at 9:11 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>>> Sorry for chiming in so late here, but I was a little surprised to see the
>>> TLS version in the GUC name. ISTM this would require us to create a new
>>> GUC for every new TLS version, or explain that ssl_tls13_ciphers isn't just
>>> for 1.3.
>
>> I agree it's not ideal. But part of the problem IMO is that we might
>> actually _have_ to introduce a new GUC for a future TLS 1.4, because
>> we have no idea if the ciphersuites will change incompatibly again. (I
>> hope not, but they did it once and they could do it again.)
>> If 1.4, or 2.0, or... 4? [1] comes out later, and it turns out to be
>> compatible, we could probably add a more appropriate alias then. (For
>> now, just as some additional data points, both Apache and Curl use
>> "1.3" or "13" in the configuration as a differentiator.) Do you have a
>> different naming scheme in mind?
In a vacuum, I would've probably voted for ssl_cipher_suites since it is
reasonably descriptive and version-independent. It's true that we'd need
lots of documentation to explain which parameter is used for which TLS
version, but I think we need that regardless of the parameter name.
> Oh yay, another naming problem :-(. I think that neither "ciphers"
> vs. "cipher suites" nor "ssl_ciphers" vs. "ssl_ciphers_tlsv13" is
> going to convey a lot to the average person who's not steeped in
> TLS minutiae. However, following the precedent of Apache and Curl
> seems like a good answer --- that will ensure that at least some
> part of the internet-using world has seen this before. So I guess
> I'm +0.5 for the ssl_ciphers_tlsv13 answer, at least out of the
> choices suggested so far.
I wasn't aware that other projects were including the version, too. IMHO
that's a fair argument for the current name, if for no other reason than
we'll be in good company if/when things change. All things considered, I'd
probably still vote for something like ssl_cipher_suites, but I'm happy to
consider the matter resolved if we've given it some thought and decided to
stick with ssl_tls13_ciphers.
--
nathan
