Re: Recent vendor SSL renegotiation patches break PostgreSQL - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: Recent vendor SSL renegotiation patches break PostgreSQL
Date
Msg-id D960CB61B694CF459DCFB4B0128514C203938193@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Recent vendor SSL renegotiation patches break PostgreSQL
List pgsql-hackers
Tom Lane wrote:
>>>> One way to deal with it would be to expose the whole renegotiation
>>>> setting as a user configuratble option. So they can set *when* we
>>>> renegotiate, which would also let them turn it off completely.
>>>
>>> Well, that might be a reasonable thing to do, because it's not just a
>>> temporary kluge (that we won't know when to remove) but is adding an
>>> arguably-useful-in-other-ways knob.
>
>> You'd still have to turn it off on the server side if you have a
>> *single* client that has the broken patch, but that's still a lot
>> better than nothing.
>
> Well, if it's a GUC it can be set per-user or per-database, so there's
> at least some hope of not having to turn it off for everyone.
>
> > Think it's worth taking a stab at?
>
> If you want to do it, I'd be fine with it.

+1

That would help me with a different problem:
SSL renegotiation is broken with Npgsql, the cause is Bug 321325
in the Mono security library
https://bugzilla.novell.com/show_bug.cgi?id=321325
which does not look like it is ever going to be fixed.

Up to now I have crippled SSL renegotiation in our servers with a patch,
because I figured that bad SSL is better than no SSL.

Yours,
Laurenz Albe


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Issues for named/mixed function notation patch
Next
From: Stefan Kaltenbrunner
Date:
Subject: SR/libpq - outbound interface/ipaddress binding