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) (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sun, 23 Jan 2022 22:09:39 +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 Grant,
>> That sounds great for a soft transition period.? I'll put a warning in
>> 2.7.0 and really remove it in 2.8.0.
>
> <ASCII thumbs up>
>
> The only other thing that I might ask is that you include the exact
> error message(s) in release notes / FAQ / what have you.? That way if
> (read: when) people hit the error and search for it (a la. fgrep -ir
> "...") they will have a nugget of information to find.
Just done.
The release notes will contain what you asked for:
* A new *docancels* parameter has been added in inn.conf to define which
types of cancels innd should process. The -C flag given to innd is
deprecated in favour of that new parameter (you'll see in your logs
the message "innd -C flag has been deprecated and has no effect; use
docancels in inn.conf" in case you're passing that flag to innd).
For the ones using CURRENT snapshots, you'll see that warning starting from
tomorrow's snapshots. Have a look at inn.conf(5) to see how to parameter
"docancels":
docancels
This parameter is intended for sites concerned about abuse of
cancels, or that wish to enforce a mechanism to authenticate
cancels. Unless rejected by the use of a filter hook, innd always
accepts and propagates cancel articles and supersede requests.
However, actually processing such articles on the local news server
depends on this parameter which can take the following values:
"require-auth"
Only articles originally protected by the Cancel-Lock
authentication mechanism can be withdrawn by a valid
authenticated cancel article or a valid authenticated supersede
request. Withdrawals of articles not originally protected by
Cancel-Lock will not be executed.
This is the default value if innd knows how to authenticate
cancels (that is to say if INN was built with Cancel-Lock
support). Otherwise, the behaviour will be the same as "none".
"auth"
Withdrawals of articles not originally protected by the Cancel-
Lock authentication mechanism will always be executed.
However, if the original article is protected, only a valid
authenticated cancel article or a valid authenticated supersede
request will permit withdrawing it. (If INN was not built with
Cancel-Lock support, such protected articles won't be
withdrawn.)
"none"
Neither cancel articles nor supersede requests will be
processed; no articles will be withdrawn.
This is the default value if innd does not know how to
authenticate cancels (that is to say if INN was not built with
Cancel-Lock support) as it has no means to ensure that these
withdrawal requests are legitimate.
"all"
innd will process all cancel articles and supersede requests,
even if unauthenticated, forged or with bad authentication.
You should be sure of what you are doing if you choose that
value as any article can be withdrawn (even by someone who is
not the author of the article).
> Aside:? Is doing the same in the source going too far?? As in "Use the
> Source Luke!".? ;-)
The exact message is naturally present in the source.
--
Julien ?LIE
??? Prends un peu de potion magique, Jolitorax??
? Mais ?a va ?tre l'heure de l'eau chaude?!?? (Ast?rix)
------------------------------
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 5
*******************************************
