Recent vendor SSL renegotiation patches break PostgreSQL
in [PgSql]
|
Prev: [HACKERS] Partial Page Writes documentaiton mention
Next: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
From: Magnus Hagander on 25 Feb 2010 04:42 On Wed, Feb 24, 2010 at 17:47, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> 2010/2/24 Tom Lane <tgl(a)sss.pgh.pa.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 25 Feb 2010 08:27 On Thu, Feb 25, 2010 at 10:42, Magnus Hagander <magnus(a)hagander.net> wrote: > On Wed, Feb 24, 2010 at 17:47, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Magnus Hagander <magnus(a)hagander.net> writes: >> Fair enough, USERSET it is then. > > Done. Will run some tests and then apply. And applied. I backpatched it to 8.2, which is as far as it applied fairly cleanly. Before that, we don't have GUC_UNIT_KB for example, so it'll be a different format of the patch as well. I'm not sure it's important enough to go back beyond that... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 25 Feb 2010 09:27 Magnus Hagander <magnus(a)hagander.net> writes: > On Wed, Feb 24, 2010 at 17:47, Tom Lane <tgl(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 25 Feb 2010 09:59 On Thu, Feb 25, 2010 at 15:27, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> On Wed, Feb 24, 2010 at 17:47, Tom Lane <tgl(a)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. You'd think so, but our entire setup of SSL on the client is designed 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 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. Agreed. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 25 Feb 2010 10:10
Magnus Hagander <magnus(a)hagander.net> writes: > I backpatched it to 8.2, which is as far as it applied fairly cleanly. > Before that, we don't have GUC_UNIT_KB for example, so it'll be a > different format of the patch as well. I'm not sure it's important > enough to go back beyond that... Hm, I'd kinda like to have it in 8.1 at least, since I'm on the hook for support of 8.1 in RHEL5. If you don't feel like messing with a further back-patch I can take a look. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |