Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Russ Allbery)
2. Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels) (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sun, 02 Jan 2022 13:54:58 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID: <[email protected]>
Content-Type: text/plain
Grant Taylor <[email protected]> writes:
> On 1/2/22 2:41 PM, Russ Allbery wrote:
>> I think it shouldn't be a no-op; it should either work to override the
>> config setting or we should remove it so that it will cause an error
>> and people will have to update their configuration. Otherwise, I think
>> we risk silent and surprising behavior change.
> I too am against the no-op.
> I'd much rather see it be a warning for one (or more) versions and
> eventually be tantamount to a syntax error to fail hard / fast.
Warnings are a bit challenging for daemons, since they tend to get eaten
by the init system and put somewhere where no one will see them. Although
since INN has its own log reporting, I suppose we could toss a warning
into the news logs and be relatively sure that someone would be notified
about it.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Sun, 2 Jan 2022 23:00:24 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Parametring cancel processing (Cancel-Lock vs
unauthenticated cancels)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> I like this idea. I suggest that the default be "require-auth" (4) if
>> INN was built with Cancel-Lock support, and "all" (1) otherwise. Or
>> maybe "none" (2) otherwise? We can do that change in the upcoming major
>> 2.7.0 release.
>
> I like this idea. I'd default to "none" otherwise (may as well be more
> secure by default, and we're allowed to break some compatibility in the
> 2.7.0 release).
OK, let's the default be the most secure ("none").
>> I also suggest removing the "innd -C" flag, or rather make it a no-op,
>> as the "docancels" parameter does the same thing, better.
>
> I think it shouldn't be a no-op; it should either work to override the
> config setting or we should remove it so that it will cause an error and
> people will have to update their configuration. Otherwise, I think we
> risk silent and surprising behavior change.
I thought of writing a notice log line for the no-op, but you're right
that it may not be seen by the news admin. Overriding the config
setting would add complexity in the (already complex) documentation and
configuration, so I'll just remove the "-C" flag then. Easy to fix with
a meaningful error log if a news admin uses that flag and updates INN to
INN 2.7.0.
Besides, if we keep "-C", a news admin may not notice that he disabled
authenticated cancels whereas he would have wanted them.
--
Julien ?LIE
??C'est une for?t vierge o? la main de l'homme n'a jamais mis le pied.??
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 137, Issue 2
*******************************************
