2010/2/22 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
Ok. If RedHat has done it, I think we're in reasonably good shape.
From what I can tell, Debian doesn't have the broken *or* non-broken
patch in, but I'm not certain.
> 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.
Yeah, seems so.
>> 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.
Yeah, the question is, how useful is it?
>> 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.
Hmm, I guess. It's a new feature, but if it's necessary..
That would take care of things on Windows as well. We could then just
disable renegotiation when we ship the known broken binaries.
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.
Think it's worth taking a stab at?
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
