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.
Once the old/new forms start getting mixed up it can be fatal, sure no
arguments there.
Amos
