Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Discussion about Cancel-Lock support (Julien ?LIE)
2. Cancels by news admin (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 Aug 2021 17:08:49 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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)
------------------------------
Message: 2
Date: Fri, 6 Aug 2021 21:27:25 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Cancels by news admin
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all, and especially news admins,
How would you see the process of sending authenticated cancels for
articles injected through your news server?
If Cancel-Lock is enabled, a hash will be added at injection time, using
a secret admin password. On news servers implementing Cancel-Lock, such
articles cannot be cancelled except when providing the corresponding key
in a cancel message. Only two persons can send that key: the user
itself, as a lock hash is also added for him unless already present, and
the news administrator.
AFAIK, there isn't any script or command in INN that currently permits
sending cancel articles to peers. (ctlinnd cancel <mid> is only local.)
One easy thing to do when implementing Cancel-Lock is to provide a new
ctlinnd command that gives the related admin keys.
Suppose you want, for any reason, to cancel an article <mid> sent by
your news server. Then you type:
% ctlinnd canlock <mid>
Cancel-Key: sha1:1k+GWLLnK+eQPvEDtUIvOgxyurY=
sha256:r4hf9OtJCfScuiuDIqi93b9qsO9Z4BQ+CUEzQ/pvQ/E=
This would be the header field to add to the cancel article (having the
admin key in both sha1 and sha256; the same algorithms used for the
initial lock hash).
Then you have to prepare a cancel article and send it (via your news
client, rnews or any other posting agent).
Would it be enough for the needs of news admins?
Otherwise, what would you need?
In the case of a script shipped with INN that directly sends the control
article (if wished), what to put in the From header field?
From: News admin <[email protected]>
with the possibility to override it?
backends/send-cancel <mid>
backends/send-cancel -f "My name <[email protected]>" <mid>
Would it be useful? Other things?
--
Julien ?LIE
??? C'est joli cette avenue le long de la mer? ?a s'appelle comment??
? La promenade des Bretons.?? (Ast?rix)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 132, Issue 3
*******************************************
