From: | Robbie Harwood <rharwood(at)redhat(dot)com> |
---|---|
To: | Nico Williams <nico(at)cryptonector(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH v18] GSSAPI encryption support |
Date: | 2018-06-12 16:36:01 |
Message-ID: | jlgr2lcgdxq.fsf@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Nico Williams <nico(at)cryptonector(dot)com> writes:
> On Mon, Jun 11, 2018 at 04:11:10PM -0400, Robbie Harwood wrote:
>> Nico was kind enough to provide me with some code review. This should
>> those concerns (clarify short-read behavior and fixing error checking on
>> GSS functions).
>
> Besides the bug you fixed and which I told you about off-list (on IRC,
> specifically), I only have some commentary that does not need any
> action:
>
> - support for non-Kerberos/default GSS mechanisms
>
> This might require new values for gssmode: prefer-<mechanism-name>
> and require-<mechanism-name>. One could always use SPNEGO if there
> are multiple mechanisms to choose from. And indeed, you could just
> use SPNEGO if the user has credentials for multiple mechanism.
>
> (Because GSS has no standard mechanism _names_, this means making
> some up. This is one obnoxious shortcoming of the GSS-API...)
As long as it's better than passing raw OIDs on the CLI...
> - when the SCRAM channel binding work is done, it might be good to add
> an option for TLS + GSS w/ channel binding to TLS and no gss wrap
> tokens
I think both of these are neat ideas if they'll be used. Getting GSSAPI
encryption in shouldn't preclude either in its present form (should make
it easier, I hope), but I'm glad to hear of possible future work as
well!
Thanks,
--Robbie
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2018-06-12 16:39:24 | Re: [PATCH v18] GSSAPI encryption support |
Previous Message | Tom Lane | 2018-06-12 16:25:58 | Re: why partition pruning doesn't work? |