Discussion about Cancel-Lock support
julien at trigofacile.com
Sun Nov 8 11:29:14 UTC 2020
Now that Cancel-Lock has been standardized in RFC 8315, maybe it is a
good time to integrate its support in INN. At last!
We already have an old ticket about that, with patches against INN 2.3.5
(that need being rewritten):
I've just had a deeper look.
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?
- 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.
- 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?
or just ship and build with INN the few files of libcanlock (under
MIT-like and BSD-3-clause for SHA algorithms)
=> different APIs of libcanlock are in the wide (API v3 is the latest
one and certainly the preferred to support; see later for possible
- 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
- 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)?
« Sol lucet omnibus. »
More information about the inn-workers