Discussion about Cancel-Lock support

[Julien ÉLIE]

Hi Russ,

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

Noted.
I'll have a look next year.  It will permit to have time to properly 
implement and test it, before eventually integrating it into a stable 
release.

Thanks for all your comments.


>> - 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.

For interoperability reasons, it seems that we'll have to handle a 
transition period, and generate two hashes for each message (SHA-1 and 
SHA-256).  And support all of the non-MD5 algorithms to verify cancel keys.

-- 
Julien ÉLIE

« Avec toutes les saletés que les gens jettent dans le fleuve, il n'y a
   plus de poissons ! Tout ce que je pêche depuis ce matin sont des
   amphores vides ! » (Astérix)