Discussion about Cancel-Lock support

[Julien ÉLIE]

Hi all,

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):
   https://inn.eyrie.org/trac/ticket/33

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?



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.

- 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 
legacy APIs)

- 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)?



Other things?

-- 
Julien ÉLIE

« Sol lucet omnibus. »