Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
От | Michael Paquier |
---|---|
Тема | Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) |
Дата | |
Msg-id | CAB7nPqTJb-syo8KN0_Ar5+A6C0F8LQ+t7UDnskYFQeVybA+5Cg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Removing SSL renegotiation (Was: Should we back-patch
SSL renegotiation fixes?)
Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?) |
Список | pgsql-hackers |
On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@anarazel.de> writes: >> On 2015-06-24 16:41:48 +0200, Andres Freund wrote: >>> I, by now, have come to a different conclusion. I think it's time to >>> entirely drop the renegotiation support. > >> I think by now we essentially concluded that we should do that. What I'm >> not sure yet is how: Do we want to rip it out in master and just change >> the default in the backbranches, or do we want to rip it out in all >> branches and leave a faux guc in place in the back branches. I vote for >> the latter, but would be ok with both variants. > > I think the former is probably the saner answer. It is less likely to > annoy people who dislike back-branch changes. And it will be > significantly less work, considering that that code has changed enough > that you won't be able to just cherry-pick a removal patch. I also fear > there's a nonzero chance of breaking stuff if you're careless about doing > the removal in one or more of the five active back branches ... +1 for removing on master and just disabling on back-branches. -- Michael
В списке pgsql-hackers по дате отправления: