Re: [PATCH] Support bump-ssl-server-first and mimic SSL server certificates

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
Received on Thu Jul 12 2012 - 00:57:03 MDT