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

From Tom Lane
Subject Re: Recent vendor SSL renegotiation patches break PostgreSQL
Date
Msg-id 27050.1266859508@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Recent vendor SSL renegotiation patches break PostgreSQL
Re: Recent vendor SSL renegotiation patches break PostgreSQL
Re: Recent vendor SSL renegotiation patches break PostgreSQL
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> 2010/2/22 Tom Lane <tgl@sss.pgh.pa.us>:
>> Red Hat's already shipping the patch. �Dunno about other vendors.

> Which patch? The one that breaks it, or the one that changes the protocol?

The one with the protocol change.

I think we already missed the window where it would have been sensible
to install a hack workaround for this.  If we'd done that in November
it might have been reasonable, but by now it's too late for any hack
we install to spread much faster than fixed openssl libraries.

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

> And it's definitely not back-patchable.

Why not?  We certainly wouldn't back-patch such a thing if we didn't
have a problem to deal with, but it's not like there's no precedent
for adding back-patched GUCs in response to security issues.  We
did that with backslash_quote.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hitoshi Harada
Date:
Subject: Reason why set-value functions not allowed in GREATEST(), etc?
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL