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 2470.1267108045@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
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Feb 24, 2010 at 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I see that ssl_ciphers is made to go away when USE_SSL isn't set,
>> so the most consistent thing in the near term would be to do the same.

> The difference is that ssl_ciphers is only set in postgresql.conf, so
> it doesn't have the same exposure. I can certainly see a use-case
> where a naive application will just disable ssl renegotiation because
> it knows it can't deal with it (or the driver can't) uncondinionally -
> but the use of SSL or not is controlled by the server at the other end
> of the connection. Not failing then would be good..

Hm, well, surely the client ought to know if the connection is actually
SSL or not.  But it's not important enough to argue about.

>> Revisiting the whole issue seems like not material for back-patching.

> Is this something we should consider looking over for 9.0,or is it too
> late already? (For other parameters, that is - a check of all the ones
> we have that are #ifdef:ed out today, to see if they can be made
> available even when the support isn't compiled in)

I don't think it's appropriate to worry about it right now.  We have
bigger issues to deal with.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: psql with GSS can crash
Next
From: Tom Lane
Date:
Subject: Re: Odd CVS revision number