From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL JDBC List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: [JDBC] Channel binding support for SCRAM-SHA-256 |
Date: | 2017-06-02 01:13:54 |
Message-ID: | CAB7nPqR4BJdCrC79Sixqh28Dh3dbojVP-sxJ65c_21cinkjiJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost <sfrost(at)snowman(dot)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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-06-02 01:14:31 | Re: logical replication and PANIC during shutdown checkpoint in publisher |
Previous Message | Tom Lane | 2017-06-02 01:13:09 | Re: Perfomance bug in v10 |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-06-02 01:25:14 | Re: [HACKERS] Channel binding support for SCRAM-SHA-256 |
Previous Message | Stephen Frost | 2017-06-02 01:08:26 | Re: [HACKERS] Channel binding support for SCRAM-SHA-256 |