>
> > Here's a patch that adds back the GUC, with default/min/max 0 and
> > GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE.
> >
> > This is my first pg patch, please be gentle with any screwups :)
>
> Why, you dummy.
>
> No, actually, this looks fine. I've committed it and back-patched
On Sun, Oct 18, 2015 at 4:56 PM, Shay Rojansky wrote:
> Here's a patch that adds back the GUC, with default/min/max 0 and
> GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE.
>
> This is my first pg patch, please be gentle with any screwups :)
Why, you dummy.
No, actually, this looks fi
Here's a patch that adds back the GUC, with default/min/max 0
and GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE.
This is my first pg patch, please be gentle with any screwups :)
patch_tolerate_ssl_renegotiation_limit_zero
Description: Binary data
--
Sent via pgsql-hackers mailing
On Oct 17, 2015, at 10:57 AM, Andres Freund wrote:
>> Rough patch for the extensible, backpatchable, non-invasive proposal
>> attached.
>
> This just doesn't make any sense. This way npgsql setting that flag can't be
> released before a new set of backbranch releases are in widespread use.
> Ot
On October 17, 2015 4:18:50 PM GMT+02:00, Simon Riggs
wrote:
>On 17 October 2015 at 14:39, Tom Lane wrote:
>
>> Andres Freund writes:
>> > Having to backpatch a new parameter to all supported versions seems
>far
>> > more invasive than adding a guc that can only be set to one value.
>>
>> Indee
On 17 October 2015 at 14:39, Tom Lane wrote:
> Andres Freund writes:
> > Having to backpatch a new parameter to all supported versions seems far
> > more invasive than adding a guc that can only be set to one value.
>
> Indeed. It is completely stupid to do this in any other way except
> by rei
Andres Freund writes:
> Having to backpatch a new parameter to all supported versions seems far
> more invasive than adding a guc that can only be set to one value.
Indeed. It is completely stupid to do this in any other way except
by reinstating ssl_renegotiation_limit as an ordinary GUC variab
On 17 October 2015 at 13:27, Andres Freund wrote:
> On 2015-10-17 12:49:17 +0100, Simon Riggs wrote:
> > Agreed, but I don't like the idea of hardcoding something so horribly
> > specific into the server.
>
> What's that specific about accepting the value for 'disabled' for a
> feature that's not
On 2015-10-17 12:49:17 +0100, Simon Riggs wrote:
> Agreed, but I don't like the idea of hardcoding something so horribly
> specific into the server.
What's that specific about accepting the value for 'disabled' for a
feature that's not supported anymore?
> I'd rather the driver added "driver=npgs
On 16 October 2015 at 14:41, Shay Rojansky wrote:
>
>> If not, the only solution I can see is for PostgreSQL to not protest if
>> it sees the
>> parameter in the startup packet.
>>
>
> Yeah, that's the ideal solution here as far as I'm concerned.
>
Agreed, but I don't like the idea of hardcoding
>
> > > If not, the only solution I can see is for PostgreSQL to not protest
> if it
> > > sees the
> > > parameter in the startup packet.
> > >
> >
> > Yeah, that's the ideal solution here as far as I'm concerned.
>
> Well, it seems that's where we're ending up then. Could you prepare a
> patch?
>
>
> As far as I remember, that was introduced because of renegotiation bugs
> with Mono:
> http://lists.pgfoundry.org/pipermail/npgsql-devel/2010-February/001074.html
> http://fxjr.blogspot.co.at/2010/03/ssl-renegotiation-patch.html
>
> Of course, with renegotiation disabled, nobody knows whether t
On 2015-10-16 16:41:16 +0300, Shay Rojansky wrote:
> > If not, the only solution I can see is for PostgreSQL to not protest if it
> > sees the
> > parameter in the startup packet.
> >
>
> Yeah, that's the ideal solution here as far as I'm concerned.
Well, it seems that's where we're ending up the
Shay Rojansky wrote:
> Just to give some added reasoning...
>
> As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've
> seen renegotiation bugs with
> the standard .NET SSL implementation (which Npgsql uses). Seems like everyone
> has a difficult time
> with renegotiation.
A
Just to give some added reasoning...
As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've
seen renegotiation bugs with the standard .NET SSL implementation (which
Npgsql uses). Seems like everyone has a difficult time with renegotiation.
As Tom suggested, it gets sent in the
Alvaro Herrera writes:
> Andres Freund wrote:
>> On 2015-10-14 14:19:40 -0300, Alvaro Herrera wrote:
>>> I think we could continue to have the parameter except that it throws an
>>> error if you try to set it to something other than 0.
>> That'll make it hard to ever remove it tho.
> What would
Andres Freund wrote:
> On 2015-10-14 14:19:40 -0300, Alvaro Herrera wrote:
> > I think we could continue to have the parameter except that it throws an
> > error if you try to set it to something other than 0.
>
> That'll make it hard to ever remove it tho.
Well, we just have to wait until 9.4 is
On 2015-10-14 14:19:40 -0300, Alvaro Herrera wrote:
> I think we could continue to have the parameter except that it throws an
> error if you try to set it to something other than 0.
That'll make it hard to ever remove it tho. Not sure if it's worth doing
so for a dubious use of the variable.
And
Andres Freund wrote:
> On 2015-10-14 13:04:30 -0400, Tom Lane wrote:
> > It doesn't seem to me that a connector such as npgsql has any business
> > whatsoever fooling with such a parameter, unconditionally or otherwise.
>
> I think in npgsql simply doesn't support renegotiation (IIRC because
> it'
On 2015-10-14 13:04:30 -0400, Tom Lane wrote:
> It doesn't seem to me that a connector such as npgsql has any business
> whatsoever fooling with such a parameter, unconditionally or otherwise.
I think in npgsql simply doesn't support renegotiation (IIRC because
it'd have been hard to implement in
Andres Freund writes:
> On 2015-10-14 18:53:14 +0300, Shay Rojansky wrote:
>> However, the new situation where some versions of PG allow this parameter
>> while others bomb when seeing it. Specifically, Npgsql sends
>> ssl_renegotiation_limit=0 in the startup packet to completely disable
>> renego
On 2015-10-14 18:53:14 +0300, Shay Rojansky wrote:
> However, the new situation where some versions of PG allow this parameter
> while others bomb when seeing it. Specifically, Npgsql sends
> ssl_renegotiation_limit=0 in the startup packet to completely disable
> renegotiation. At this early stage
Hi hackers.
I noticed ssl_renegotiation_limit has been removed in PostgreSQL 9.5, good
riddance...
However, the new situation where some versions of PG allow this parameter
while others bomb when seeing it. Specifically, Npgsql sends
ssl_renegotiation_limit=0 in the startup packet to completely d
23 matches
Mail list logo
