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.
Received on Thu Jul 12 2012 - 15:31:23 MDT
This archive was generated by hypermail 2.2.0 : Mon Jul 16 2012 - 12:00:03 MDT