Re: [PATCH v12] GSSAPI encryption support
От | Robert Haas |
---|---|
Тема | Re: [PATCH v12] GSSAPI encryption support |
Дата | |
Msg-id | CA+TgmoZF2J5C=BghUcpzFGWLSDpRb8eWc2RhiyEze4vj0zbhaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH v12] GSSAPI encryption support (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [PATCH v12] GSSAPI encryption support
|
Список | pgsql-hackers |
On Thu, Apr 7, 2016 at 10:17 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > 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? Yeah, I think so. It doesn't seem we have consensus on this, and it's too late to be trying to build one now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: