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

OK, I'll see how to get rid of the verifycancels stuff.
Couldn't refusecybercancels also be removed?  Its default value is 
already false and our inn.conf documentation mentions it is a "somewhat 
messy, inefficient, and inexact way of refusing spam cancels"...



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

I've begun to look at the integration of Cancel-Lock support.
I believe the possibility to have several secret phrases could be 
useful, notably to deal with a period of transition when changing the 
password (during which 2 Cancel-Key hashes will be sent).
A bit like how extra overview fields are advertised in LIST OVERVIEW.FMT 
(there are 2 parameters:  what to advertise at the current time, and 
what "hidden fields" to generate, and that will be advertised later).

Better follow best practice right now as for new configuration files (it 
will ease a future migration).

Suggestion:
- add a "secretsfile" inn.conf parameter for the path to the secrets 
file (<pathetc>/secrets.conf by default?)
- use the new INN configuration parser for it

cancels {
   canlockuser: password
   canlockadmin: otherpassword
   extracanlockuser:
   extracanlockadmin:
}

I don't see use cases for more than 2 passwords so a list might be 
over-kill for extracanlockuser & admin).

cancels {
   canlockuser: password
   canlockadmin: otherpassword
   extracanlockuser: oldpassword
   extracanlockadmin: oldotherpassword
}

would generate 2 Cancel-Lock hashes with canlockuser & admin, and 4 
Cancel-Key hashes with all the 4 passwords when a cancel or supersedes 
is sent.
If there aren't any passwords, or the related keys are missing, the 
function is de-activated.

Perhaps the cancels group is not useful, and we could just have in 
secrets.conf:

canlockuser: password
canlockadmin: otherpassword
extracanlockuser: oldpassword
extracanlockadmin: oldotherpassword





Re-reading our doc/config-syntax file, I also see that we could use an 
included file as a group:
   group tag <filename>

Hmmm, if we use in inn.conf something like:

secrets cancels <pathetc>/secrets.cancels
secrets passwd <pathetc>/secrets.passwd (for the purpose of current 
passwd.nntp)
secrets feeds <pathetc>/secrets.feeds (where we could put the passwords 
of incoming.conf and innfeed.conf)

wouldn't it respond to the need of secrets file?

I still have not played with the possibilities of the parser; it seems 
that construction is possible.  It is then unclear if the referenced 
file can list parameters/values (like inn.conf) or if it has to contain 
groups {}.  Then we could have 1 secret file with cancels/feeds/etc. 
groups (or without groups).

Any thoughts?

-- 
Julien ÉLIE

« Passion is inversely proportional to the amount of real information
   available. » (Benford's law)