Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

> > > 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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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,

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

> > > > 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?

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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.

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

> > 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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

[HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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.

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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 >

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

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