I wrote: > If we want to go any further back with 1.1 support, we have a range > of options: > 1. Back-patch that patch, probably also including the followup adjustments > in 86029b31e and 36a3be654. > 2. Add #if's to use 31cf1a1a4's coding with OpenSSL >= 1.1, while keeping > the older code for use when built against older OpenSSLs. > 3. Conditionally disable renegotiation altogether with OpenSSL >= 1.1, > thus adopting 9.5 not 9.4 behavior when using newer OpenSSL.
> I think #3 would be fairly weird unless we also changed 9.4 similarly. > But there's some argument for doing that: we don't really have any field > experience with using renegotiation with OpenSSL 1.1, so we don't know > that what is in the 9.4 branch right now actually works with 1.1. > On the other hand, it would also be the most work of these options, > since we'd have to do things like adding conditional behavior in guc.c. I did some simple testing and can say that at least the successful path in the 9.4 code seems to be fine with 1.1; in particular I see no sign of the misbehavior discussed in https://www.postgresql.org/message-id/flat/20150126101405.GA31719%40awork2.anarazel.de Given Heikki's opinion that that was an OpenSSL bug, perhaps they fixed the bug. Certainly we don't seem to have committed any of the workaround patches discussed in that thread. At this point I'd be inclined to reject option #3: aside from being more work, it'd be a pain to document, and confusing for users. I have a slight preference for #1 over #2 --- we'd intended to back-patch Alvaro's fixes once they had survived some field use, and I know of no evidence that 9.4 is worse than the older 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
