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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Дата
Msg-id CAB7nPqQOFSn-PYpEXawFx5Gh0CSwX6kPR4ib+T5qmd7OVsV=PA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Stephen Frost <sfrost@snowman.net>)
Ответы 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 Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost <sfrost@snowman.net> wrote:
> I don't have any issue with asking that Michael, or someone, to go look
> at other OpenSSL-using implementations which support channel binding.

I don't see the implementation of other TLS/SSL as a requirement for
channel binding with OpenSSL, and I have no plans to investigate that.
What is clearly a requirement though is to design a set of API generic
enough for the backend and the frontend to fetch the TLS unique
message, and what's needed for endpoint so as any implementation can
plug in easily with PG's channel binding code.

> 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.  I'm exaggerating
> for effect here, of course, and you've agreed that a full, committable,
> implementation isn't necessary, and I agreed with that, but we still
> seem to have a different level of expectation regarding what needs doing
> here.  I don't know that we'll ever be able to nail down the exact
> location of the line in the sand that needs to be crossed here, or agree
> to it, so I'd suggest that we let them continue their efforts to work
> together and provide a patch which they feel is ready to be commented on
> by committers.  Perhaps we'll find that, regardless of where the line
> was drawn exactly, they've crossed it.

As far as I can see, there are a couple of things that I still need to
work on to make people happy:
- Rework the generic APIs for TLS finish and endpoint so as any
implementation can use channel binding without inducing any extra code
footprint to be-secure.c and fe-secure.c.
- Implement endpoint, as Alvaro is saying for JDBC that would be nicer.
- Have a couple of tests for channel binding to allow people to test
the feature easily. Those will be in src/test/ssl/. It would be nice
as well to be able to enforce the channel binding type on libpq-side,
which is useful at least for testing. So we are going to need an
environment variable for this purpose, and a connection parameter.
--
Michael


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

Предыдущее
От: Beena Emerson
Дата:
Сообщение: Re: [HACKERS] Default Partition for Range
Следующее
От: amul sul
Дата:
Сообщение: Re: [HACKERS] [POC] hash partitioning