On 07/11/2012 06:56 PM, Amos Jeffries wrote: > On 12.07.2012 10:58, Amos Jeffries wrote: >> On 12.07.2012 03:33, Alex Rousskov wrote: >>> On 07/11/2012 06:38 AM, Amos Jeffries wrote: >>> >>>> * why is is FATAL: error to have old ssl_bump allow/deny values in the >>>> config? >>>> can we auto-convert the "allow" to client-first and deny to bump-none >>>> with very loud ERROR: messages instead? we can calculate what the >>>> implicit negate would have been and add it explicitly with another loud >>>> warning. >>> >>> I have struggled with this decision. Yes, we could auto-convert old >>> configs (using client-first for the implicit allow rule, if any), but >>> then some folks will start using a mixture of old and new keywords or >>> would expect a simple 's/allow/server-first/;s/deny/none/' to work. I >>> think it is safer to force a manual intervention here, especially since >>> SslBump config should not be taken lightly, and client-first is really >>> not the best default. >>> >>> If the above arguments did not convince you, or others insist on >>> auto-conversion, we will add it. We would still reject a mixture of old >>> and new keywords though. >>> >>> Do you still think auto-conversion is the best approach here? > > there are two changes that can be made in complete safety: > * auto-convert of deny->none in all cases. > * making 'allow' non-fatal when -k parse is run, so that all problems > can be detected and fixed easily. > > I'm not going to pressure auto-conversion of "allow" for production > servers, but I think we can and should do it in the name of backward > compatibility despite the required conversion not being the best config. > Squid will then at least run as-is after an upgrade is installed without > immediate manual intervention.
OK, we will auto-convert non-mixed cases, with a deprecation warning. Thank you, Alex.
