Discussion about Cancel-Lock support

[Russ Allbery]

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

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

Yes, I think we should remove refusecybercancels.  It was always a hack
and I don't think anyone is issuing mass spam cancels using that
convention any more (or probably has in more than a decade).

Other readers of inn-workers, yell if this is something you think is still
useful.

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

Yes, supporting key rotation is always a good idea.

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

I'm not sure that I understand the difference between canlockuser and
extracanlockuser.  They both result in sending a hash, and they are both
valid for verifying hashes, correct?  If that's the case, it may be
simpler to remove the extra* parameters and just make the values lists.

I like the idea of a separate secrets file.

One of my past regrets was when I was looking at configuration file
formats, I probably shouldn't have hand-rolled a parser and instead
figured out how to use YAML.  In my defense, at the time it was far from
obvious that YAML would win the configuration language wars (and I guess
it hasn't entirely won them even now), and there were a lot of other
possibilities.  But now I kind of wish all the INN configuration files
were just in YAML.  The popularity of Kubernetes among other things has
made YAML fairly universal, with great editor, linting, and schema
support.  Ah well.  Maybe a project for some future day when someone is
feeling wildly ambitious.  :)

(And yes, I know YAML is hideously, absurdly complicated and there are a
lot of language features you probably don't want to use.  But it's still
the most readable and writable configuration language for humans IMO, even
with its strange quirks and aggressive interpretation of words as
booleans.)

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

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

I feel like we have other secrets that could potentially benefit from this
over time, though (passwd.nntp, for instance, or the secret parameter in
inn-radius.conf), so I like the grouping.  It feels more future-proof.  It
would be lovely if eventually we could put all the secrets used by INN in
one file, since that makes life much easier for configuration management
and permissions.

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

This would also work but I think I like the first syntax a bit better.

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

My recollection is that if you use the group tag <filename> syntax, the
contents of the filename are treated as if they are contained in a group
{} block.  But it's been a very long time....

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