Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On Fri, Jun 26, 2015 at 9:59 AM, Andres Freund and...@anarazel.de wrote: Generally I'd agree that that is a bad thing. But there's really not much of a observable behaviour change in this case? Except that connections using ssl break less often. Well, SSL renegotiation exists for a reason: to improve security. It's not awesome that we're being forced to shut off features that are designed to improve security. But it seems we have little choice, at least until we can support some other SSL implementation (and maybe not even then). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Robert Haas robertmh...@gmail.com writes: On Fri, Jun 26, 2015 at 9:59 AM, Andres Freund and...@anarazel.de wrote: Generally I'd agree that that is a bad thing. But there's really not much of a observable behaviour change in this case? Except that connections using ssl break less often. Well, SSL renegotiation exists for a reason: to improve security. That was the theory, yes, but the CVEs that have come out of it indicate that whether it improves security *in practice* is a pretty debatable topic. The fact that the new TLS draft drops it altogether tells us something about the conclusion the standards community has arrived at. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 2015-06-26 10:26:58 -0400, Robert Haas wrote: On Fri, Jun 26, 2015 at 9:59 AM, Andres Freund and...@anarazel.de wrote: Generally I'd agree that that is a bad thing. But there's really not much of a observable behaviour change in this case? Except that connections using ssl break less often. Well, SSL renegotiation exists for a reason: to improve security. Well, except that even if it were implemented correctly it's far from clear cut that it's a win: If your argument is that key-rotation is beneficial because it gives an attacker less encrypted material to analyze: That's not a good argument, you're just giving him more information about the assymetric crypto side of things instead about the session key which is ephemeral anyway. I think they only real argument for it is that you want to limit the amount of data you could decrypt if you gain access to the current symmetric key via the client's memory . But that's not a particularly large benefit. But it seems we have little choice, at least until we can support some other SSL implementation (and maybe not even then). I read through one other SSL implementation (NSS), and I don't think it's substantially better handled there. At least one other implementations is ripping out support entirely already. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On Thu, Jun 25, 2015 at 8:03 AM, Andres Freund and...@anarazel.de wrote: I don't accept the argument that there are not ways to tell users about things they might want to do. We probably could do that. But why would we want to? It's just as much work, and puts the onus on more people? Because it doesn't force a behavior change down everyone's throat. If it were just a question of back-porting fixes, even someone invasive ones, well, maybe that's what we have to do; that's pretty much exactly what we are planning to do for the MultiXact case, but according to Heikki, this is broken even in master and can't really be fixed unless and until OpenSSL gets their act together. That's a hard argument to argue with, and I think I'm on board with it. But as a general point, we should be very reluctant to force behavior changes on our users in released branches, because users don't like that. When there are reasonable alternatives to doing that, we should choose them. If we have no other reasonable choice here, so be it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 2015-06-26 09:53:30 -0400, Robert Haas wrote: On Thu, Jun 25, 2015 at 8:03 AM, Andres Freund and...@anarazel.de wrote: I don't accept the argument that there are not ways to tell users about things they might want to do. We probably could do that. But why would we want to? It's just as much work, and puts the onus on more people? Because it doesn't force a behavior change down everyone's throat. Generally I'd agree that that is a bad thing. But there's really not much of a observable behaviour change in this case? Except that connections using ssl break less often. If it were just a question of back-porting fixes, even someone invasive ones, well, maybe that's what we have to do; that's pretty much exactly what we are planning to do for the MultiXact case There's no way we can reasonably disable multixacts, so I don't think these situations are comparable. but according to Heikki, this is broken even in master and can't really be fixed unless and until OpenSSL gets their act together. Yes, that's my conclusion as well, leading to my position in this thread. That's a hard argument to argue with, and I think I'm on board with it. Given that reported bugs for openssl around this have existed since about 2002 without any effort at fixing, I think it's seriously unlikely that they ever will. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 06/26/2015 04:53 PM, Robert Haas wrote: On Thu, Jun 25, 2015 at 8:03 AM, Andres Freund and...@anarazel.de wrote: I don't accept the argument that there are not ways to tell users about things they might want to do. We probably could do that. But why would we want to? It's just as much work, and puts the onus on more people? Because it doesn't force a behavior change down everyone's throat. It's arguable whether this is a change in behaviour or not. SSL renegotiation is (supposed to be) completely transparent to the user. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 06/25/2015 03:03 PM, Andres Freund wrote: The situation is this: We have broken code using broken code. I think we either got to apply, darn nontrivial, fixes from http://archives.postgresql.org/message-id/54DE6FAF.6050005%40vmware.com or we got to cripple the options. It's also not the first breakage, we've applied a lot of bandaids to this code already. Our way of doing renegotiation also has broken several SSL client implementations... Note that even with those patches, renegotiation is still broken in some scenarios: http://www.postgresql.org/message-id/54dcf736.2060...@vmware.com. As far as I can tell, OpenSSL's handling of renegotiation is fundamentally broken, and there is nothing we can do in the application to completely work around that. +1 for changing the default to disable renegotiation, in all branches. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 2015-06-24 17:20:31 -0400, Robert Haas wrote: On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund and...@anarazel.de wrote: On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote: On 6/24/15 3:13 PM, Andres Freund wrote: Meh. The relevant branches already exist, as you can disable it today. We could also just change the default in the back branches. One more argument for leaving everything alone. If users don't like it, they can turn it off themselves. Because it's so obvious to get there from SSL error: unexpected message, SSL error: bad write retry or SSL error: unexpected record to disabling renegotiation. Right? Search the archives and you'll find plenty of those, mostly in relation to streaming rep. It took -hackers years to figure out what causes those, how are normal users supposed to a) correlate such errors with renegotiation b) evaluate what do about it? We could document the issues, create release-note entries suggesting a configuration change, and/or blog about it. The situation is this: We have broken code using broken code. I think we either got to apply, darn nontrivial, fixes from http://archives.postgresql.org/message-id/54DE6FAF.6050005%40vmware.com or we got to cripple the options. It's also not the first breakage, we've applied a lot of bandaids to this code already. Our way of doing renegotiation also has broken several SSL client implementations... Right now if you use streaming rep over ssl, it breaks after a couple hundred megabytes with obscure errors. The user might or might not notice that. He might just see errors around syncrep or something. Or notice that logical decoding never finishes streaming out one huge as xact, or ... I don't accept the argument that there are not ways to tell users about things they might want to do. We probably could do that. But why would we want to? It's just as much work, and puts the onus on more people? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 6/25/15 8:03 AM, Andres Freund wrote: Right now if you use streaming rep over ssl, it breaks after a couple hundred megabytes with obscure errors. If it's that bad, then I tend to agree we should turn it off by default. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 06/25/2015 06:15 AM, Peter Eisentraut wrote: On 6/25/15 8:03 AM, Andres Freund wrote: Right now if you use streaming rep over ssl, it breaks after a couple hundred megabytes with obscure errors. If it's that bad, then I tend to agree we should turn it off by default. From an in the wild perspective, we run into this all the time. +1 to turn it off by default in all supported branches. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing I'm offended is basically telling the world you can't control your own emotions, so everyone else should do it for you. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund and...@anarazel.de wrote: On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote: On 6/24/15 3:13 PM, Andres Freund wrote: Meh. The relevant branches already exist, as you can disable it today. We could also just change the default in the back branches. One more argument for leaving everything alone. If users don't like it, they can turn it off themselves. Because it's so obvious to get there from SSL error: unexpected message, SSL error: bad write retry or SSL error: unexpected record to disabling renegotiation. Right? Search the archives and you'll find plenty of those, mostly in relation to streaming rep. It took -hackers years to figure out what causes those, how are normal users supposed to a) correlate such errors with renegotiation b) evaluate what do about it? We could document the issues, create release-note entries suggesting a configuration change, and/or blog about it. I don't accept the argument that there are not ways to tell users about things they might want to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On Wed, Jun 24, 2015 at 3:41 PM, Peter Eisentraut pete...@gmx.net wrote: On 6/24/15 3:13 PM, Andres Freund wrote: Meh. The relevant branches already exist, as you can disable it today. We could also just change the default in the back branches. One more argument for leaving everything alone. If users don't like it, they can turn it off themselves. I find it very hard to disagree with that perspective. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. Yes, +1 for backpatching. Don't forget 5674460b and b1aebbb6. Huh? 5674460b is ancient, and we concluded that b1aebbb6 didn't represent anything much more than cosmetic fixes. Sorry, I mixed up 5674460b with 36a3be65 which you already mentioned ... and I see that because of the conclusions from 272923a0a695 then the one-char change in b1aebbb6 is not very interesting. I do think that perhaps we should simplify the code down to what 272923a0a695 + 1c2b7c0879d8 do. I also agree that the other changes by Andres and Heikki, which involve making all communication use a nonblocking socket, seem too invasive to backpatch; even with the insurance provided by beta+release, the disruptiveness of changes seems a bit too high, considering that 387da18874a apparently cannot be used without 4f85fde8eb which is a bit scary in itself. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Robert Haas robertmh...@gmail.com writes: On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund and...@anarazel.de wrote: On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote: One more argument for leaving everything alone. If users don't like it, they can turn it off themselves. Because it's so obvious to get there from SSL error: unexpected message, SSL error: bad write retry or SSL error: unexpected record to disabling renegotiation. Right? Search the archives and you'll find plenty of those, mostly in relation to streaming rep. It took -hackers years to figure out what causes those, how are normal users supposed to a) correlate such errors with renegotiation b) evaluate what do about it? We could document the issues, create release-note entries suggesting a configuration change, and/or blog about it. I don't accept the argument that there are not ways to tell users about things they might want to do. I think there's a strong argument for changing the default setting to zero (no renegotiation), even in the back branches. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote: On 6/23/15 2:33 PM, Tom Lane wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. If Red Hat fixes their bug, then PostgreSQL doesn't have any actual problem anymore, does it? It does, there are numerous bugs around renegotiation that exist with upstream openssl and postgres. More in the older branches, but even in HEAD we break regularly. Most only occur in replication connections (due to copy both) and/or when using more complex clients where clients and servers send data at the same time due to pipelining. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 6/23/15 2:33 PM, Tom Lane wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. If Red Hat fixes their bug, then PostgreSQL doesn't have any actual problem anymore, does it? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Andres Freund and...@anarazel.de writes: On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote: If Red Hat fixes their bug, then PostgreSQL doesn't have any actual problem anymore, does it? It does, there are numerous bugs around renegotiation that exist with upstream openssl and postgres. More in the older branches, but even in HEAD we break regularly. Most only occur in replication connections (due to copy both) and/or when using more complex clients where clients and servers send data at the same time due to pipelining. The lesson to learn from the Red Hat fiasco is that vendors are not adequately testing renegotiation either. All the more reason to get out from under it. I did not like being told that Postgres fails and $randomapp doesn't, therefore it's Postgres' problem when actually the difference was that $randomapp doesn't invoke renegotiation. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 6/24/15 3:13 PM, Andres Freund wrote: Meh. The relevant branches already exist, as you can disable it today. We could also just change the default in the back branches. One more argument for leaving everything alone. If users don't like it, they can turn it off themselves. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote: On 6/24/15 3:13 PM, Andres Freund wrote: Meh. The relevant branches already exist, as you can disable it today. We could also just change the default in the back branches. One more argument for leaving everything alone. If users don't like it, they can turn it off themselves. Because it's so obvious to get there from SSL error: unexpected message, SSL error: bad write retry or SSL error: unexpected record to disabling renegotiation. Right? Search the archives and you'll find plenty of those, mostly in relation to streaming rep. It took -hackers years to figure out what causes those, how are normal users supposed to a) correlate such errors with renegotiation b) evaluate what do about it? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On 6/24/15 12:26 PM, Tom Lane wrote: Andres Freund and...@anarazel.de writes: On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote: If Red Hat fixes their bug, then PostgreSQL doesn't have any actual problem anymore, does it? It does, there are numerous bugs around renegotiation that exist with upstream openssl and postgres. More in the older branches, but even in HEAD we break regularly. Most only occur in replication connections (due to copy both) and/or when using more complex clients where clients and servers send data at the same time due to pipelining. The lesson to learn from the Red Hat fiasco is that vendors are not adequately testing renegotiation either. All the more reason to get out from under it. I did not like being told that Postgres fails and $randomapp doesn't, therefore it's Postgres' problem when actually the difference was that $randomapp doesn't invoke renegotiation. I'm fine with removing renegotiation. But the original proposal was to backpatch renegation changes, which seemed like replacing one problem variation with another, and does not sound comfortable given recent backpatching record. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On June 24, 2015 9:07:35 PM GMT+02:00, Peter Eisentraut pete...@gmx.net wrote: On 6/24/15 12:26 PM, Tom Lane wrote: Andres Freund and...@anarazel.de writes: On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote: If Red Hat fixes their bug, then PostgreSQL doesn't have any actual problem anymore, does it? It does, there are numerous bugs around renegotiation that exist with upstream openssl and postgres. More in the older branches, but even in HEAD we break regularly. Most only occur in replication connections (due to copy both) and/or when using more complex clients where clients and servers send data at the same time due to pipelining. The lesson to learn from the Red Hat fiasco is that vendors are not adequately testing renegotiation either. All the more reason to get out from under it. I did not like being told that Postgres fails and $randomapp doesn't, therefore it's Postgres' problem when actually the difference was that $randomapp doesn't invoke renegotiation. I'm fine with removing renegotiation. But the original proposal was to backpatch renegation changes, which seemed like replacing one problem variation with another, and does not sound comfortable given recent backpatching record. Meh. The relevant branches already exist, as you can disable it today. We could also just change the default in the back branches. --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Should we back-patch SSL renegotiation fixes?
Those of you who have been following http://www.postgresql.org/message-id/flat/1d3bc192-970d-4b70-a5fe-38d2a9f76...@me.com are aware that Red Hat shipped a rather broken version of openssl last week. While waiting for them to fix it, I've been poking at the behavior, and have found out that PG 9.4 and later are much less badly broken than older branches. In the newer branches you'll see a failure only after transmitting 2GB within a session, whereas the older branches fail at the second renegotiation attempt, which would typically be 1GB of data and could be a lot less. I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. (There are more changes in master, but since those haven't yet shipped in any released branch, and there's been a lot of other rework in the same area, those probably are not back-patch candidates.) Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: Those of you who have been following http://www.postgresql.org/message-id/flat/1d3bc192-970d-4b70-a5fe-38d2a9f76...@me.com are aware that Red Hat shipped a rather broken version of openssl last week. While waiting for them to fix it, I've been poking at the behavior, and have found out that PG 9.4 and later are much less badly broken than older branches. In the newer branches you'll see a failure only after transmitting 2GB within a session, whereas the older branches fail at the second renegotiation attempt, which would typically be 1GB of data and could be a lot less. I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. (There are more changes in master, but since those haven't yet shipped in any released branch, and there's been a lot of other rework in the same area, those probably are not back-patch candidates.) Thoughts? I have no clear idea how safe it is to back-port these fixes. Just as a point of reference, we had a customer hit a problem similar to bug #12769 on 9.3.x. I think (but am not sure) that 272923a0a may have been intended to fix that issue. In a quick search, I didn't find any other complaints about renegotiation-related issues from our customers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Robert Haas wrote: On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. (There are more changes in master, but since those haven't yet shipped in any released branch, and there's been a lot of other rework in the same area, those probably are not back-patch candidates.) Yes, +1 for backpatching. Don't forget 5674460b and b1aebbb6. I could reproduce problems trivially with COPY in psql without that and a small renegotiation limit, as I recall. Thoughts? I have no clear idea how safe it is to back-port these fixes. Just as a point of reference, we had a customer hit a problem similar to bug #12769 on 9.3.x. I think (but am not sure) that 272923a0a may have been intended to fix that issue. Maybe we should *also* backpatch that, then (and if so, then also its fixup 1c2b7c087). I do not think that the failure was introduced by the fixes cited above. In a quick search, I didn't find any other complaints about renegotiation-related issues from our customers. Other issues Andres was investigating seemed related to nonblocking connections (which as I recall are used mostly by replication code). Bug #12769 contained a link to the previous discussion. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Robert Haas robertmh...@gmail.com writes: On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. (There are more changes in master, but since those haven't yet shipped in any released branch, and there's been a lot of other rework in the same area, those probably are not back-patch candidates.) Thoughts? I have no clear idea how safe it is to back-port these fixes. Well, it would mean that pre-9.5 branches all behave the same, which would be an improvement in my book. Also, ISTM that the 9.4 code for renegotiation assumes a whole lot less than prior branches about OpenSSL's internal behavior; so it ought to be more robust, even if some bugs remain. Just as a point of reference, we had a customer hit a problem similar to bug #12769 on 9.3.x. I think (but am not sure) that 272923a0a may have been intended to fix that issue. In a quick search, I didn't find any other complaints about renegotiation-related issues from our customers. The problem with trying to adopt code from HEAD is that it probably depends on the rather invasive changes explained here: http://www.postgresql.org/message-id/20150126101405.ga31...@awork2.anarazel.de Even assuming that there's no dependency on the immediate-interrupt changes, I'm afraid to back-patch anything that invasive. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
Alvaro Herrera alvhe...@2ndquadrant.com writes: On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. Yes, +1 for backpatching. Don't forget 5674460b and b1aebbb6. Huh? 5674460b is ancient, and we concluded that b1aebbb6 didn't represent anything much more than cosmetic fixes. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should we back-patch SSL renegotiation fixes?
On Tue, Jun 23, 2015 at 3:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote: I do not know at this point whether these behaviors are really the same bug or not, but I wonder whether it's time to consider back-patching the renegotiation fixes we did in 9.4. Specifically, I think maybe we should back-patch 31cf1a1a4, 86029b31e, and 36a3be654. (There are more changes in master, but since those haven't yet shipped in any released branch, and there's been a lot of other rework in the same area, those probably are not back-patch candidates.) Thoughts? I have no clear idea how safe it is to back-port these fixes. Well, it would mean that pre-9.5 branches all behave the same, which would be an improvement in my book. Also, ISTM that the 9.4 code for renegotiation assumes a whole lot less than prior branches about OpenSSL's internal behavior; so it ought to be more robust, even if some bugs remain. Just as a point of reference, we had a customer hit a problem similar to bug #12769 on 9.3.x. I think (but am not sure) that 272923a0a may have been intended to fix that issue. In a quick search, I didn't find any other complaints about renegotiation-related issues from our customers. The problem with trying to adopt code from HEAD is that it probably depends on the rather invasive changes explained here: http://www.postgresql.org/message-id/20150126101405.ga31...@awork2.anarazel.de Even assuming that there's no dependency on the immediate-interrupt changes, I'm afraid to back-patch anything that invasive. What commits actually resulted from that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
