Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Дата
Msg-id CA+TgmoZu1qgz4UTYxa8SP0yEj4VkjwoBFTuyeErOmcVEuxA8uw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] Channel binding support for SCRAM-SHA-256  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> What I find somewhat objectionable is the notion that if we don't have 5
>> different TLS/SSL implementations supported in PG and that we've tested
>> that channel binding works correctly among all combinations of all of
>> them, then we can't accept a patch implementing it.
>
> It seems to me that any testing in this area won't fly high as long as
> there is no way to enforce the list of TLS implementations that a
> server allows. There have been discussions about being able to control
> that after the OpenSSL vulnerabilities that were protocol-specific and
> there were even patches adding GUCs for this purpose. At the end,
> everything has been rejected as Postgres enforces the use of the
> newest one when doing the SSL handshake.

TLS implementations, or TLS versions?  What does the TLS version have
to do with this issue?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] "create publication..all tables" ignore 'partition notsupported' error
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher