From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Chris Campbell <chris_campbell(at)mac(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Recent vendor SSL renegotiation patches break PostgreSQL |
Date: | 2010-02-25 09:42:27 |
Message-ID: | 9837222c1002250142t6207b73etc198035c924a1844@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 24, 2010 at 17:47, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> 2010/2/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Also, the coding seems a bit confused about whether the
>>> ssl_renegotiation_limit GUC exists when USE_SSL isn't set. I think we
>>> have a project policy about whether GUCs should still exist when the
>>> underlying support isn't compiled, but I forget what it is :-(.
>
>> I personally find it highly annoying when a GUC goes away, so I'm all
>> for always having them there. And I thought that was our policy for
>> new ones, but I can't find a reference to it...
>
> 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..
> 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)
>>> SUSET seems less surprising to me. I agree that it's hard to make
>>> a concrete case for a user doing anything terribly bad with it,
>>> but on the other hand is there much value in letting it be USERSET?
>
>> The use case would be for example npgsql (or npgsql clients) being
>> able to disable it from the client side, because they know they can't
>> deal with it. Even in the case that the server doesn't know that.
>
> Fair enough, USERSET it is then.
Done. Will run some tests and then apply.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | marcin mank | 2010-02-25 09:55:48 | Re: Streaming rep - why log shipping is necessary? |
Previous Message | Heikki Linnakangas | 2010-02-25 09:35:30 | Odd CVS revision number |