Discussion about Cancel-Lock support

Russ Allbery eagle at eyrie.org
Mon Nov 30 02:09:19 UTC 2020


Julien ÉLIE <julien at trigofacile.com> writes:

> First:  do you all agree that support for Cancel-Lock/Key should be
> natively integrated in both innd and nnrpd? (in C source code) or do you
> prefer only an update to Perl filter hook samples to add an example of
> code to deal with that feature?

I think it's fine to integrate it directly since it will be an inn.conf
option.  It may be worth considering getting rid of verifycancels while
we're at it to reduce some complexity, since the check it enables is
essentially meaningless and RFC 5537 actively recommends against this.
Cancel-Lock support is the correct approach to achieve the same ends
(although of course most people don't generate Cancel-Lock headers).

> General features:
> - comply with RFC 8315 (Cancel-Lock)

> - when an article is posted, a user cancel lock is added (unless
>   existing), and always an admin cancel lock is added

> - when a cancel (or supersedes) is posted, a user cancel key is always added

> - when a cancel (or supersedes) is received, it is checked, whether one of
>  the keys matches one of the locks. If yes, the cancel is
>  honoured. Otherwise, it has no effect, but is still accepted and relayed

> - no check at injection time by nnrpd of the validity of a provided cancel
>  key.  Indeed, we may no longer have the original article in the spool to
> check that.  If the cancel key is wrong, or the original article had no
> lock, the cancel will just not be honoured.

This all sounds good.

> - rely on libcanlock (check for presence at configure time)
> => OK with that?  new --with-canlock option (like --with-perl) and the
> functionality is not available if libcanlock is not installed?

Yes, I think this is the right approach.  libcanlock is already packaged
for Debian, and I'm not a fan of including copies of code that someone
else is already maintaining when we can avoid it.

> - new inn.conf parameters:
>   * canlockuser (default to <pathetc>/canlock.usr) to store the secret
>     passphrase used for the user lock (uid+secret)
>   * canlockadmin (default to <pathetc>/canlock.adm) to store the secret
>     passphrase used for the news administrator lock

Yeah, this is probably fine.  It would be nice if we had a general secrets
configuration for INN, but we don't, and this is probably the easiest way
to go forward.

> - which hash algorithm to support? and how?
> I suggest not to generate nor honour md5 hashes.
> But what for sha1, sha224, sha256, sha384 and sha512?  Honour all of them
> but generate only sha256 and/or sha512?
> Force for instance the generation of sha256 (the only MANDATORY algorithm
> in RFC 8315)?  or parameter the one to use?  or parameter all that should
> be used (multiple locks and keys to add)?

My inclination would be to support all of the non-MD5 algorithms for
verification but only generate SHA-256.  I don't think there's much gained
by using the other algorithms.

It looks like Gnus still only supports SHA-1.

-- 
Russ Allbery (eagle at eyrie.org)             <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.


More information about the inn-workers mailing list