Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

2015-10-24 Thread Shay Rojansky
> > > 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

2015-10-20 Thread Robert Haas
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

2015-10-18 Thread Shay Rojansky
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

2015-10-17 Thread Andres Freund
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

2015-10-17 Thread Simon Riggs
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

2015-10-17 Thread Simon Riggs
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

2015-10-17 Thread Tom Lane
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

2015-10-17 Thread Simon Riggs
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

2015-10-17 Thread Robert Haas
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

2015-10-17 Thread Andres Freund
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

2015-10-16 Thread Shay Rojansky
> > > > 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

2015-10-16 Thread Albe Laurenz
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

2015-10-16 Thread Andres Freund
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

2015-10-16 Thread Shay Rojansky
> > 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

2015-10-14 Thread Andres Freund
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

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

2015-10-14 Thread Shay Rojansky
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

2015-10-14 Thread Andres Freund
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

2015-10-14 Thread Andres Freund
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

2015-10-14 Thread Alvaro Herrera
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

2015-10-14 Thread Alvaro Herrera
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

2015-10-14 Thread Tom Lane
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

2015-10-14 Thread Tom Lane
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