Towards a 2.4.4 release

[Alexander Bartolich]

Heiko Schlichting wrote:
> [...]
> But it is fairly easy to implement processing Cancel-Lock/Cancel-Key with
> or without using libcanlock. The biggest problem is to guarantee that the
> person who tries to cancel is the author of the original article. If you
> can't guarantee this, inserting a Cancel-Key is not allowed (and not
> useful).
 >
 > Using IP based access control, this is impossible. In all other cases it
 > could be hard to impossible anyway, so we have to use our database to find
 > the unique userid of the original article and compare it with the userid of
 > the cancel posting attempt.

If you use a scheme based on username/password then the verified username
is available in filter_nnrpd.pl. The Cancel-Key is then based on three values:
- the message ID of the target ($message_id),
- the username sending the post ($user),
- and a site wide secret key (CANCEL_LOCK).

   return MIME::Base64::encode(
     Digest::HMAC_SHA1::hmac_sha1($message_id, $user . CANCEL_LOCK), ''
   );

This way only the holder of the original account can create a matching key.

Verification of Cancel-Lock/Cancel-Key then happens in filter_nnrpd.pl.
Typically cancel messages or supersedes with invalid keys are ignored
(i.e. stored in news spool like a regular article).

However, if the first word of X-Trace: matches your own site name than
that article is coming from a local user and should be rejected if the
Cancel-Key does not match the Cancel-Lock. It is not necessary to know
the user ID for that check.

Ciao

     Alexander.