On Thu, Feb 25, 2010 at 15:27, Tom Lane wrote:
Magnus Hagander <[email protected]> writes:
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.
Magnus Hagander <[email protected]> writes:
On Wed, Feb 24, 2010 at 17:47, Tom Lane 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, soI 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.
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..
SSL or not. But it's not important enough to argue about.
on the assumption that it doesn't ;)
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 toolate 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)
bigger issues to deal with.
