Re: Recent vendor SSL renegotiation patches break PostgreSQL

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: Recent vendor SSL renegotiation patches break PostgreSQL
Дата
Msg-id D960CB61B694CF459DCFB4B0128514C203938193@exadv11.host.magwien.gv.at
обсуждение исходный текст
Ответ на Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Issues for named/mixed function notation patch
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: SR/libpq - outbound interface/ipaddress binding