On Wed, Mar 22, 2017 at 09:32:01PM +0100, Frederic Lecaille wrote: > > (...) > > > "sslv2" disables "no-sslv3", > > > "ssl-reuse" disables "no-ssl-reuse", > > > "stick" disables "non-stick", > > > "tlsv10" disables "no-tlsv10", > > > "tlsv11" disables "no-tlsv11", > > > "tlsv12" disables "no-tlsv12", > > > "tls-tickets" disables "no-tls-tickets". > > > > Hmmm I hadn't thought about these ones, I suspect they'll cause more > > confusion than anything else, especially given that the "tlsv11" above > > cancelling "no-tlsv11" is not the same as "force-tlsv11". We need to > > discuss this with Emeric, he's already scratching his head around these > > ones without these double negations, he will hate us now :-) > > > Yes I agree. I should have asked about this before posting.
No, quite the opposite, it's much better to open the discussion here with more people sharing ideas. > But from my > point of view this is only a naming issue which may easily fixed. Definitely, yes. > Why no adding synonyms prefixed by "disallow-" for the existing "no(n)-*" > options, and rename my silly new options to "allow-*"? > > Or with "forbid(permit)-*" prefix (suffix)? The thing is that we already use "no" for many other options to disable the effect of a possible default setting. And we were not the first ones, due to some network vendors having been doing this over the last 25 years, most network equipments also use "no" to disable a default statement :-) > Anything else? > > "no-force-*" is not very English, even for me ;) > Could be replaced by "do-not-force-*" but it's quite long. We do have some "dont" (abbreviated) at some places. The rule with "no-" in front of any keyword is easier to remember even when it causes some strange wording than having better sounding names for some exceptions. And this discussion is a perfect example, users will see that "no-" fails and wonder "ah what's the f*cking prefix for this one". The real trouble in my opinion really is the "foo" to cancel the "no-foo" statements whose goal was to disable foo already. Taking sslv3 as an example, by default it's enabled. By setting "no-sslv3" in a default-server we disable it for all servers. And if we don't want to disable it for a given server, that would not be "sslv3" which would make one think we want to force it, and the theorical "no-no-sslv3" doesn't parse well either. It could be "enable-sslv3" for example. But given that there's currently a discussion ongoing between Manu and Emeric regarding how to deal with long-term SSL versions, it's very possible that the outcome of their head-scratching sessions will bring the solution. I've seen them suggest min- and max- to set version ranges, that could then easily solve the problem by suggesting that we deprecate the use of no-sslv3 or no-tlsv1 in favor of these names with explicit arguments. One (short) discussion I had with Emeric already went into that direction, we realized that Manu's min- and max- suggestion would solve a lot of problems with some adjustments and would still allow us to support most valid existing no-ssl-XYZ setups by converting them to an internal min+max range an map "force-ssl-xyz" to min=max=xyz, that would ease config transitions and reject unsupported configs opening holes (eg: no-tlsv11 when upper and lower ones are still supported). Emeric also suggested that in order to avoid the trouble of adding many keywords and making parsers painful for API developers, instead of having, say, min-tls11 we could in fact have "min-tls 1.1" with 1.1 being an argument. As you have noticed, by playing like this we automatically remove the need for "no-no-tls11" and "no-force-tls11" for example since min-tls / max-tls can override them :-) Thus I'm really not worried for these ones, what matters is that everyone can configure what they need in a safe and durable way. Cheers, Willy
