>
> > 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
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,
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 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
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
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
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
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
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
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
>
> > > 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?
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.
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
>
> 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
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
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
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.
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 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
>
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
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
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
22 matches
Mail list logo