> Le 22 mars 2017 à 22:58, Willy Tarreau <[email protected]> a écrit : > > On Wed, Mar 22, 2017 at 05:30:09PM +0100, Emmanuel Hocdet wrote: >> I have patches sent in the ML who change the internal implementation of >> no/force-tlsxx and add min/max-tlsxx (who can replace no/force usage). >> It could simplify (or not) what you want to do, but there will be an impact >> on your patches if they are accepted. > > Yes, as I said in the other mail I think that's on a good track but as > Emeric suggested we'd rather have them provide an argument instead of > using the keyword name, that will make it much easier to process. We > can still support most older valid use cases and use warnings to explain > how to convert that to the new mode (if really needed, not even sure) and > emit errors explaining what to do for the situations that openssl does > not support anymore (holes in the range). >
Emeric's suggestion is not on the ML. If no- and force- are defined as deprecated it can make a difference. I'm not used to seeing this kind of proposal for haproxy configuration ;-) (for the hole, openssl low leveling the range: no-tlsv1.1 become max-tlsv1.0) ++ Manu
