Re: Support for NSS as a libpq TLS backend

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Support for NSS as a libpq TLS backend
Дата
Msg-id 9B16F5EA-5F01-4E9D-BDD7-8E0D2166D6F5@yesql.se
обсуждение исходный текст
Ответ на Re: Support for NSS as a libpq TLS backend  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Support for NSS as a libpq TLS backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Add regression test for recovery pause.
Следующее
От: David Christensen
Дата:
Сообщение: DELETE CASCADE