Re: [PATCH v12] GSSAPI encryption support

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [PATCH v12] GSSAPI encryption support
Дата
Msg-id CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH v12] GSSAPI encryption support  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH v12] GSSAPI encryption support  (Robert Haas <robertmhaas@gmail.com>)
Re: [PATCH v12] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
Список pgsql-hackers
On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robbie Harwood <rharwood@redhat.com> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> Wait a second.  So the initial connection-request packet is necessarily
>>> unencrypted under this scheme?
>
>> Yes, by necessity.  The username must be sent in the clear, even if only
>> as part of the GSSAPI handshake (i.e., the GSSAPI username will appear
>> in plantext in the GSSAPI blobs which are otherwise encrypted).  GSSAPI
>> performs authentication before it can start encryption.
>
> Ugh.  I had thought we were putting work into this because it represented
> something we could recommend as best practice, but now you're telling me
> that it's always going to be inferior to what we have already.

It does not seem necessary to have an equivalent of
pqsecure_open_client, just some extra handling in fe-connect.c to set
up the initial context with a proper message handling... Not that
direct anyway. So should the patch be marked as returned with feedback
at this stage?
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix for OpenSSL error queue bug
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Timeline following for logical slots