Robbie, all,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Michael Paquier writes:
> > On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood
> > wrote:
> >> Michael Paquier writes:
> >>
> >> So there's a connection setting `sslmode` that we'll want something
> >> similar to here (`gssapimode` or
Michael Paquier writes:
> On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood wrote:
>> Michael Paquier writes:
>>
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
>> think we only need three for GSSA
On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>
>> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote:
>>> Robbie Harwood writes:
>>
>> Sorry for my late reply.
>
> Thanks for the feedback!
>
If I were to continue as I have been - using the plaintext
Tom Lane writes:
> Robbie Harwood writes:
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
>> think we only need three for GSSAPI: "disable", "allow", and "prefer"
>> (which presumably would be the
Robbie Harwood writes:
> So there's a connection setting `sslmode` that we'll want something
> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
> think we only need three for GSSAPI: "disable", "allow", and "prefer"
> (which presumably would be the default).
FWIW, there is
Robbie Harwood writes:
> So there's a connection setting `sslmode` that we'll want something
> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
> think we only need three for GSSAPI: "disable", "allow", and "prefer"
> (which presumably would be the default).
Apologies, th
Michael Paquier writes:
> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote:
>> Robbie Harwood writes:
>
> Sorry for my late reply.
Thanks for the feedback!
>>> If I were to continue as I have been - using the plaintext connection
>>> and auth negotiation path - then at the time of startu
On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote:
> Robbie Harwood writes:
Sorry for my late reply.
>> I think in order to satisfy Tom's (valid) concern, there does need to be
>> a separate handshake - i.e., GSSAPI support in pqsecure_open_client().
Having the communication layer in fe-se
Robbie Harwood writes:
> Michael Paquier writes:
>
>> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
>>> Robbie Harwood writes:
Tom Lane writes:
> Wait a second. So the initial connection-request packet is
> necessarily unencrypted under this scheme?
>>>
Yes, by neces
Michael Paquier writes:
> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
>> Robbie Harwood writes:
>>> Tom Lane 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
On Fri, Apr 8, 2016 at 2:36 PM, Stephen Frost wrote:
> While it seems like this particular patch (with myself as committer)
> would meet the requirements stated by the RMT for an extension, having
> considered it over the past day or so, I don't think we should make it a
> policy to allow an exten
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 7, 2016 at 10:17 PM, Michael Paquier
> wrote:
> > On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
> >> Robbie Harwood writes:
> >>> Tom Lane writes:
> Wait a second. So the initial connection-request packet is necessarily
> u
On Thu, Apr 7, 2016 at 10:17 PM, Michael Paquier
wrote:
> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
>> Robbie Harwood writes:
>>> Tom Lane writes:
Wait a second. So the initial connection-request packet is necessarily
unencrypted under this scheme?
>>
>>> Yes, by necessity. Th
On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
> Robbie Harwood writes:
>> Tom Lane 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
Robbie Harwood writes:
> Tom Lane 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 appe
Tom Lane writes:
> Robbie Harwood writes:
>> I need to flush this any time we might be doing encryption because it
>> needs to be in a separate request to _secure_write() from what follows
>> it. We don't know whether we should be doing encryption until
>> connection parameters are parsed; to p
Robbie Harwood writes:
> I need to flush this any time we might be doing encryption because it
> needs to be in a separate request to _secure_write() from what follows
> it. We don't know whether we should be doing encryption until
> connection parameters are parsed; to put it another way,
> port
Stephen Frost writes:
> Just an initial pass over the patch.
Thanks! In the interest of brevity, if I haven't replied to something,
I plan to fix it.
>> /*
>> - * Flush message so client will see it, except for AUTH_REQ_OK, which
>> need
>> - * not be sent until we are ready for
Robbie,
Just an initial pass over the patch.
* Robbie Harwood (rharw...@redhat.com) wrote:
> Here's v12, both here and on my github:
> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12
I've started taking a look at this as it's a capability I've wanted us
to support for a *lon
On Wed, Apr 6, 2016 at 5:58 AM, Alvaro Herrera wrote:
> Robbie Harwood wrote:
>> Alvaro Herrera writes:
>> > It seems to me that the right solution for this is to create a new
>> > memory context which is a direct child of TopMemoryContext, so that
>> > palloc can be used, and so that it can be r
On Wed, Apr 6, 2016 at 6:15 AM, Magnus Hagander wrote:
> On Tue, Apr 5, 2016 at 7:58 PM, Robbie Harwood wrote:
>>
>> > -#if defined(WIN32) && !defined(WIN32_ONLY_COMPILER)
>> > -/*
>> > - * MIT Kerberos GSSAPI DLL doesn't properly export the symbols for
>> > MingW
>> > - * that contain the OIDs r
On Tue, Apr 5, 2016 at 7:58 PM, Robbie Harwood wrote:
> > -#if defined(WIN32) && !defined(WIN32_ONLY_COMPILER)
> > -/*
> > - * MIT Kerberos GSSAPI DLL doesn't properly export the symbols for MingW
> > - * that contain the OIDs required. Redefine here, values copied
> > - * from src/athena/auth/kr
Robbie Harwood wrote:
> Alvaro Herrera writes:
> > It seems to me that the right solution for this is to create a new
> > memory context which is a direct child of TopMemoryContext, so that
> > palloc can be used, and so that it can be reset separately, and that it
> > doesn't suffer from resets
On 4/5/16 1:25 AM, Michael Paquier wrote:
> Btw, those seem like small things to me, and my comments have been
> addressed, so I have switched the patch as ready for committer. I
> guess that Stephen would be the one to look at it.
I have also run this patch through my tests and didn't find any
p
Alvaro Herrera writes:
> Robbie Harwood wrote:
>> Michael Paquier writes:
>>
>> > On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote:
>> >> Here's v12, both here and on my github:
>> >> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12
>
>> > So you are saving everything i
Robbie Harwood wrote:
> Michael Paquier writes:
>
> > On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote:
> >> Here's v12, both here and on my github:
> >> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12
> > So you are saving everything in the top memory context. I am fin
Michael Paquier writes:
> On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote:
>> Here's v12, both here and on my github:
>> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12
>>
> +#ifdef ENABLE_GSS
> + {
> + MemoryContext save = CurrentMemoryContext;
> + Curren
On Tue, Apr 5, 2016 at 9:06 AM, Robbie Harwood wrote:
> Here's v12, both here and on my github:
> https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12
>
> What changed:
>
> - The code is aware of memory contexts now. I actually really like the
> memory context stuff; just didn't
Hello friends,
Here's v12, both here and on my github:
https://github.com/frozencemetery/postgres/tree/feature/gssencrypt12
What changed:
- The code is aware of memory contexts now. I actually really like the
memory context stuff; just didn't see any indication of its existence
in the code
29 matches
Mail list logo
