Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 9B16F5EA-5F01-4E9D-BDD7-8E0D2166D6F5@yesql.se
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Support for NSS as a libpq TLS backend  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On 3 Jun 2021, at 22:14, Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Thu, 2021-06-03 at 15:53 -0400, Andrew Dunstan wrote:
>> Yeah, but it's annoying to have to start every talk I give touching
>> this
>> subject with the slide that says "When we say SSL we really means
>> TLS".
>> Maybe release 15 would be a good time to rename user-visible option
>> names etc, with support for legacy names.

Perhaps.  Having spent some time in this space, SSL has IMHO become the de
facto term for an encrypted connection at the socket layer, with TLS being the
current protocol suite (additionally, often referred to SSL/TLS).  Offering
tls* counterparts to our ssl GUCs etc will offer a level of correctness but I
doubt we'll ever get rid of ssl* so we might not help too many users by the
added complexity.

It might also put us a hard spot if the next TLS spec ends up being called
something other than TLS?  It's clearly happened before =)

> Sounds good to me, though I haven't looked into how big of a diff that
> will be.
>
> Also, do we have precedent for GUC aliases? That might be a little
> weird.

I don't think we do currently, but I have a feeling the topic has surfaced here
before.

If we end up settling on this being something we want I can volunteer to do the
legwork, but it seems a discussion best had before a patch is drafted.

--
Daniel Gustafsson        https://vmware.com/




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Add regression test for recovery pause.
Next
From: David Christensen
Date:
Subject: DELETE CASCADE