Re: Cancel-Lock mit sha1 oder sha256

[Thomas Hochstein]

Peter Heirich schrieb:

> Wenn man sucht, findet man
>
> https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html
>
> auch die GIT-Resource https://code.th-h.de/?p=usenet/INN.git kann offenbar
> nur md5/sha1.

Das ist korrekt. Beides basiert auf Postings von 2007 in
de.comm.software.newsserver (wo das Thema m.E. auch eher hingehört als in
eine Gruppe für Anfängerfragen zum Usenet). :)

Soweit ich sehe, kann der Code auch mit Header-Folding nicht korrekt
umgehen.

> Die Alternative in https://home.gegeweb.org/rfc8315.html ist m.E.
> schwierig zu finden.

Sie hat, AFAIS, dasselbe Problem mit Header-Folding, ist aber sonst
freilich vorzugswürdig.

> zus?lich zum sha256 noch einen sha1 cancel-lock in die header
> schreiben. Lt. RFC bzw. Draft-RFC sind, falls ich das richtig verstanden
> habe, sind mehrere cancel-locks, auch mit unterschiedlichen hash
> algorithmen, m?ch.

So würde ich das machen.

> Meine Bef?ng ist, dass RFC8315 erst in weiteren 5-10 Jahren
> weitgehend umgesetzt ist.

Unwahrscheinlich. Die meisten Newsserver, die heute noch betrieben werden,
werden einigermaßen aktiv gepflegt. INN 2.7.0 unterstützt
Cancel-Lock/Cancel-Key "out of the box" (AFAIS über libcanlock), sobald
der für die großen Distributionen paketiert ist, hat sich das Thema
erledigt. Das demnächst releaste Debian bookworm bringt 2.7.1 mit.

-thh

XP/Fup2 de.comm.software.newsserver

[Peter Heirich]

Thomas Hochstein wrote:


>
>Das ist korrekt. Beides basiert auf Postings von 2007 in
>de.comm.software.newsserver (wo das Thema m.E. auch eher hingehört als in
>eine Gruppe für Anfängerfragen zum Usenet). :)

Hatte ich auch überlegt, aber Cancel-Lock sollte mehr im Newsreader
erstellt werden, eher weniger im Newsserver. Newsreadersoftware wäre
Cancel durch User, Newsserver eher Admin-Cancel.

Wegen der Prinzipfrage sha1 / sha256 an sich wollte ich nicht in die
Newsservergruppe.

>
>Soweit ich sehe, kann der Code auch mit Header-Folding nicht korrekt
>umgehen.

Habe ich mich (noch) nicht mit beschäfftigt.

>Unwahrscheinlich. Die meisten Newsserver, die heute noch betrieben werden,
>werden einigermaßen aktiv gepflegt. INN 2.7.0 unterstützt
>Cancel-Lock/Cancel-Key "out of the box" (AFAIS über libcanlock), sobald
>der für die großen Distributionen paketiert ist, hat sich das Thema
>erledigt. Das demnächst releaste Debian bookworm bringt 2.7.1 mit.
>

Dank für die Info. Ich fahre da CentOS 8 Stream und inn 2.6.5

>
>XP/Fup2 de.comm.software.newsserver

Bitte, gerne

Peter

[Peter Heirich]

Thomas Hochstein wrote:


>So würde ich das machen.

Ich habe mal beide Codes gemischt, es scheinen jetzt sha256 + sha1
cancel-locks geschrieben zu werden. Hässlich, ich weiss. Irgendwie mochte
er hmac_sha1_base64 nicht, obwohl es die lt. Beschreibung von
Digest::SHA.pm geben soll.

Kann man erfolgreiche Cancel auf Fremdservern irgendwie testen?

filter_nnrpd.pl:



#
# Do any initialization steps.
#
use Digest::SHA qw( sha256_base64 hmac_sha256_base64 sha1 );
use Digest::HMAC_SHA1();
use MIME::Base64();


$CANCEL_LOCK = 'secretword';



#
# Filter
#
sub filter_post {
my $rval = "" ; # assume we'll accept.
$modify_headers = 1;

# Cancel-Lock / Cancel-Key
add_cancel_lock(\%hdr, $user);

if (exists( $hdr{"Control"} ) && $hdr{"Control"} =~ m/^cancel\s+(<[^>]+>)/i) {
my $key = calc_cancel_key_256($user, $1);
add_cancel_item(\%hdr, 'Cancel-Key', $key, 'sha256');
# #hitd
# uncomment next 2 lines if additional sha1 cancel-key should be sent
$key = calc_cancel_key_1($user, $1);
add_cancel_item(\%hdr, 'Cancel-Key', $key, 'sha1');
}
elsif (exists( $hdr{"Supersedes"} )) {
my $key = calc_cancel_key_256($user, $hdr{"Supersedes"});
add_cancel_item(\%hdr, 'Cancel-Key', $key, 'sha256');
# #hitd
# uncomment next 2 lines if additional sha1 cancel-key should be sent
$key = calc_cancel_key_1($user, $hdr{"Supersedes"});
add_cancel_item(\%hdr, 'Cancel-Key', $key, 'sha1');
}

return $rval;
}

#
# Cancel-Lock / Cancel-Key
#
sub add_cancel_item($$$$) {
my ( $r_hdr, $name, $value, $algo ) = @_;
my $prefix = $r_hdr->{$name};
$prefix = defined($prefix) ? $prefix . " $algo:" : "$algo:";
$r_hdr->{$name} = $prefix . $value;
}


sub calc_cancel_key_256($$) {
my ( $user, $message_id ) = @_;
return pad_b64digest(hmac_sha256_base64($message_id, $user . $CANCEL_LOCK));
}

sub calc_cancel_key_1($$) {
my ( $user, $message_id ) = @_;
return MIME::Base64::encode(Digest::HMAC_SHA1::hmac_sha1($message_id, $user . $CANCEL_LOCK), '');
#return pad_b64digest(hmac_sha1_base64($message_id, $user . $CANCEL_LOCK));
}

sub add_cancel_lock($$) {
my ( $r_hdr, $user ) = @_;
my $key = calc_cancel_key_256($user, $r_hdr->{'Message-ID'});
my $lock = pad_b64digest(sha256_base64($key));
add_cancel_item($r_hdr, 'Cancel-Lock', $lock, 'sha256');

# #hitd
# remove comment from next 3 lines, if additional sha1 cancel lock
# will be expected
$key = calc_cancel_key_1($user, $r_hdr->{'Message-ID'});
$lock = MIME::Base64::encode(Digest::SHA::sha1($key), '');
add_cancel_item($r_hdr, 'Cancel-Lock', $lock, 'sha1');
}

sub pad_b64digest($) {
my ($b64_digest) = @_;
while (length($b64_digest) % 4) {
$b64_digest .= '=';
}
return $b64_digest;
}

[Peter Heirich]

Peter Heirich wrote:
>
>filter_nnrpd.pl:

cleanfeed.local ist eigentlich unverändert zum alten sha256 Stand. Ich
habe 2 minimale Änderungen gemacht.
1) Erfolgreiche Cancel protokolliert, zumindest zunächst einmal. Gab es
als Kommentar im Code schon.
2) minimale Änderung der erfolgreichen Protokollierung

if (exists($lock{$key})) {
# INN::syslog('notice', "Valid Cancel-Key $key found.$msg");
INN::syslog('notice', "Valid $lock{$key} Cancel-Key $key found.$msg");
# -thh
# article is canceled now

$lock{$key} enthält den genutzten Hashalgorithmus, also "sha1" oder "sha256". ist aber nur etwas Verschönerung.


cleanfeed.local:

# vim: set syntax=perl ts=4 ai si:

use Digest::SHA qw( sha1_base64 sha256_base64 sha512_base64 );
use Digest::MD5 qw( md5_base64 );

#
# local_filter_cancel
#
sub local_filter_cancel {
unless($hdr{Control} =~ m/^cancel\s+(<[^>]+>)/i) {
return "Cancel with broken target ID";
}
return verify_cancel(\%hdr, $1, 'Cancel');
}

sub local_filter_after_emp {
if (exists( $hdr{'Supersedes'} )) {
#return verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
# verify_cancel is called, but not returned, so the
# posting is unconditionally accepted
# verify_cancel calls INN:cancel() if verification suceeds
verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
}

return undef;
}

sub verify_cancel($$$) {
my $r_hdr = shift || die;
my $target = shift;
my $descr = shift;

my $headers = INN::head($target) || return "$descr of non-existing ID $target";

my %headers;
for my $line(split(/\s*\n/, $headers)) {
if ($line =~ m/^([[:alnum:]-]+):\s+(.*)/) {
$headers{$1} = $2;
}
}

my $lock = $headers{'Cancel-Lock'};
if (defined($lock)) {
my $key = $r_hdr->{'Cancel-Key'} || return "$descr of $target without Cancel-Key";
#return verify_cancel_key($key, $lock, ' target=' . $target);
return verify_cancel_key($key, $lock, $target);
} else {
# -thh
# no cancel-lock: go ahead and cancel anyway!
INN::cancel($target);
}

return undef;
}

sub verify_cancel_key($$$) {
my $cancel_key = shift;
my $cancel_lock = shift;
my $msg = shift;

$msg = '' unless(defined($msg));
# -thh
my $target = $msg;
$msg = ' target=' . $msg;

my %lock;
for my $l(split(/\s+/, $cancel_lock)) {
next unless($l =~ m/^(sha512|sha256|sha1|md5):(\S+)/);
$lock{$2} = $1;
}

for my $k(split(/\s+/, $cancel_key)) {
unless($k =~ m/^(sha512|sha256|sha1|md5):(\S+)/) {
INN::syslog('notice', "Invalid Cancel-Key syntax '$k'.$msg");
next;
}

my $key;
if ($1 eq 'sha512') {
$key = sha512_base64($2);
}
elsif ($1 eq 'sha256') {
$key = sha256_base64($2);
}
elsif ($1 eq 'sha1') {
$key = sha1_base64($2);
}
elsif ($1 eq 'md5') {
$key = md5_base64($2);
}
$key = pad_b64digest($key);

if (exists($lock{$key})) {
# INN::syslog('notice', "Valid Cancel-Key $key found.$msg");
INN::syslog('notice', "Valid $lock{$key} Cancel-Key $key found.$msg");
# -thh
# article is canceled now
INN::cancel($target) if ($target);
return undef;
}
}

INN::syslog('notice',
"No Cancel-Key[$cancel_key] matches Cancel-Lock[$cancel_lock]$msg"
);
return "No Cancel-Key matches Cancel-Lock.$msg";

}

sub pad_b64digest($) {
my ($b64_digest) = @_;
while (length($b64_digest) % 4) {
$b64_digest .= '=';
}
return $b64_digest;
}

1;

[Michael Bäuerle]

Peter Heirich wrote:
> Thomas Hochstein wrote:
> >
> > Das ist korrekt. Beides basiert auf Postings von 2007 in
> > de.comm.software.newsserver (wo das Thema m.E. auch eher hingehört als in
> > eine Gruppe für Anfängerfragen zum Usenet). :)
>
> Hatte ich auch überlegt, aber Cancel-Lock sollte mehr im Newsreader
> erstellt werden, eher weniger im Newsserver. Newsreadersoftware wäre
> Cancel durch User, Newsserver eher Admin-Cancel.

Üblich ist, dass der Newsserver das stellvertretend für die Benutzer
macht (so dass es auch mit Newsreadern ohne Cancel-Lock-Unterstützung
funktioniert).

> Wegen der Prinzipfrage sha1 / sha256 an sich wollte ich nicht in die
> Newsservergruppe.

Für die Übergangszeit sollte man bei Versand und Prüfung beides
verwenden.

Bei ausreichend breiter Unterstützung von SHA256 kann man irgendwann
die Prüfung für SHA1 abschalten.

[Thomas Hochstein]

Peter Heirich schrieb:

> Kann man erfolgreiche Cancel auf Fremdservern irgendwie testen?

Im Zweifel mit einem Account dort?

[Thomas Hochstein]

Peter Heirich schrieb:

> Thomas Hochstein wrote:
>> Das ist korrekt. Beides basiert auf Postings von 2007 in
>> de.comm.software.newsserver (wo das Thema m.E. auch eher hingehört als in
>> eine Gruppe für Anfängerfragen zum Usenet). :)
>
> Hatte ich auch überlegt, aber Cancel-Lock sollte mehr im Newsreader
> erstellt werden, eher weniger im Newsserver.

Theoretisch sehe ich das ebenso, praktisch gibt es nur noch eine Handvoll
Newsreader, die überhaupt noch weiterentwickelt werden, so dass der Header
für eine relevante Verbreitung sinnvollerweise auch vom Server gesetzt
werden sollte. Für Admincancel muss er das sogar.

Zudem erfolgt die Umsetzung - also die Prüfung des Cancel-Keys - ja in
jedem Fall auf dem Server. Das ist m.E. eher kein Client-Thema.

> Wegen der Prinzipfrage sha1 / sha256 an sich wollte ich nicht in die
> Newsservergruppe.

Wenn, dann findet man da ja diejenigen, die das serverseitig
implementieren und Deine Frage beantworten können, ob es sha256 bereits
ausreichend verbreitet ist. ;-)

-thh
--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>

[Peter Heirich]

Thomas Hochstein wrote:

>
>>Kann man erfolgreiche Cancel auf Fremdservern irgendwie testen?
>
>Im Zweifel mit einem Account dort?

Ich hätte gehofft, dass irgendwelche Reflektoren in einer Testgruppe
helfen könnten.

Peter

[Thomas Hochstein]

Peter Heirich schrieb:

>>> Kann man erfolgreiche Cancel auf Fremdservern irgendwie testen?

[...]

>
> Ich hätte gehofft, dass irgendwelche Reflektoren in einer Testgruppe
> helfen könnten.

Ah! Guter Gedanke.

Cancel wohl nicht - die dürften in der Regel, wie alle Steuernachrichten,
ausgefiltert werden -, aber Supersedes müssten tun. Wobei ... hm, auch die
würden standardmäßig wohl in jedem Fall akzeptiert, auch wenn der damit
verbundene Cancel nicht ausgeführt werden würde.

Nein, hilft wohl nicht.

Aber wenn Du irgendwas in einer Testgruppe cancelst, kannst Du gerne
Bescheid geben, dann kann ich bei mir ins Log gucken, ob der Cancel
ausgeführt wurde.

[Peter Heirich]

Thomas Hochstein wrote:

>Aber wenn Du irgendwas in einer Testgruppe cancelst, kannst Du gerne
>Bescheid geben, dann kann ich bei mir ins Log gucken, ob der Cancel
>ausgeführt wurde.

Danke für das Angebot, aber unlängst war deine Aussage, dass mit INN 2.7.x
Cancel-Lock out-of-the Box kommt. Das sollte dann gut getestet sein.

Insofern reicht es mir derzeit, dass ich die Cancel-Locks manuell nach RFC
nachgerechnet habe.

Der gepostete Perl-Code müsste "nachgebessert" und getestet werden, wenn
er mehr als ein Notbehelf sein soll. Da er, wie von dir bereits angeführt,
mit multi-line folding wohl nicht korrekt funktioniert.

Peter

[Thomas Hochstein]

Peter Heirich schrieb:

> Thomas Hochstein wrote:
>
>> Aber wenn Du irgendwas in einer Testgruppe cancelst, kannst Du gerne
>> Bescheid geben, dann kann ich bei mir ins Log gucken, ob der Cancel
>> ausgeführt wurde.
>
> Danke für das Angebot, aber unlängst war deine Aussage, dass mit INN 2.7.x
> Cancel-Lock out-of-the Box kommt. Das sollte dann gut getestet sein.

AFAIS wird dann schlicht libcanlock benutzt.

> Insofern reicht es mir derzeit, dass ich die Cancel-Locks manuell nach RFC
> nachgerechnet habe.

Okay. :) Mich hätte interessiert, ob mein Server jetzt auch Cancel-Locks
und -Keys mit sha256 verarbeiten kann, aber das kann ich dann ja
irgendwann auch mal selbst testen.

> Der gepostete Perl-Code müsste "nachgebessert" und getestet werden, wenn
> er mehr als ein Notbehelf sein soll. Da er, wie von dir bereits angeführt,
> mit multi-line folding wohl nicht korrekt funktioniert.

Should be fixed.

[Marcel Logen]

Thomas Hochstein in de.comm.software.newsserver:

>Peter Heirich schrieb:

[...]

>> Insofern reicht es mir derzeit, dass ich die Cancel-Locks manuell nach RFC
>> nachgerechnet habe.
>
>Okay. :) Mich hätte interessiert, ob mein Server jetzt auch Cancel-Locks
>und -Keys mit sha256 verarbeiten kann, aber das kann ich dann ja
>irgendwann auch mal selbst testen.

<9c52e4d1c0619462...@o15.ybtra.de>
<news:9c52e4d1c0619462...@o15.ybtra.de>

und (hoffentlich dazu passend)

<cancel.9c52e4d1c061...@o15.ybtra.de>
<news:cancel.9c52e4d1c061...@o15.ybtra.de>

>> Der gepostete Perl-Code müsste "nachgebessert" und getestet werden, wenn
>> er mehr als ein Notbehelf sein soll. Da er, wie von dir bereits angeführt,
>> mit multi-line folding wohl nicht korrekt funktioniert.
>
>Should be fixed.

Daran habe ich bei obigem Test leider nicht gedacht.
Das kann ich ja dann noch nachschieben.

Marcel
--
─╮ ..10..╭──────────────╮ ╭───╮ ╭─╮ ╭──╮ ╭────╮ ╭───╮ ╭─╮
╰──╮ ..10..╰────────╮ ╰──╯ ╰─╯ ╰──╯ ╰─╯ ╭─╯ ╭─╯ ╰─╯ ╰──╮
│ ╭─╮ ╭──╮ ╭───╯ ╰───╯ ..60..╭───╯ ╭
╰──╯ ╰───╯ ╰───╯ ..60..╰─────╯

[Marcel Logen]

Marcel Logen in de.comm.software.newsserver:

>Thomas Hochstein in de.comm.software.newsserver:
>>Peter Heirich schrieb:

[...]

>>> Der gepostete Perl-Code müsste "nachgebessert" und getestet werden, wenn
>>> er mehr als ein Notbehelf sein soll. Da er, wie von dir bereits angeführt,
>>> mit multi-line folding wohl nicht korrekt funktioniert.
>>
>>Should be fixed.
>
>Daran habe ich bei obigem Test leider nicht gedacht.
>Das kann ich ja dann noch nachschieben.

<321cac1cb9490079...@o15.ybtra.de>
<news:321cac1cb9490079...@o15.ybtra.de>

und

<cancel.321cac1cb949...@o15.ybtra.de>
<news:cancel.321cac1cb949...@o15.ybtra.de>

Marcel
--
╭────╮ ╭─╮ ╭──────╮ ╭───╮ ╭─────╮ ╭───────────╮ ╭──────╮ ╭───
╯ ╭─╯ │ ╰──╯..15..╰────╯ ╰─╯ ╰─╮ ╭─╯ ╭─╮ ╭────╯ ╰──╮ │ │
╰─╮ ╰─╮ ..31..╭──╯ │ │ ╰─╯ ╭─╮ ╭─╮ ╰─╮ │ ╰─╮
╰────╯ ..31..╰────╯ ╰─────╯ ╰─╯ ╰────╯ ╰────╯

[Thomas Hochstein]

Marcel Logen schrieb:

> Thomas Hochstein in de.comm.software.newsserver:

>> Okay. :) Mich hätte interessiert, ob mein Server jetzt auch Cancel-Locks
>> und -Keys mit sha256 verarbeiten kann, aber das kann ich dann ja
>> irgendwann auch mal selbst testen.
>
> <9c52e4d1c0619462...@o15.ybtra.de>

| news@weidegrund $ grep '<9c52e4d1c0619462...@o15.ybtra.de>' /var/log/news/news.notice
| May 20 20:20:00 weidegrund innd: SERVER cancelled <9c52e4d1c0619462...@o15.ybtra.de>

> und (hoffentlich dazu passend)
>
> <cancel.9c52e4d1c061...@o15.ybtra.de>

| news@weidegrund $ sm `grephistory '<cancel.9c52e4d1c061...@o15.ybtra.de>'` | grep Cancel
| Cancel-Key: sha256:jH0/c959CWsCSLJoTLI7sIancq2zkAgpzQmVwbXuoeM=

Ich bin höchst entzückt, allerbestesten Dank!

-thh

[Thomas Hochstein]

Marcel Logen schrieb:

> <321cac1cb9490079...@o15.ybtra.de>

| news@weidegrund $ grep '<321cac1cb9490079...@o15.ybtra.de>' /var/log/news/news.notice

| May 20 20:20:00 weidegrund innd: SERVER cancelled <9c52e4d1c0619462...@o15.ybtra.de>

Der Cancel hat funktioniert.

| Cancel-Lock: sha1:trallala/123+123+123+123+45=
| sha256:Vt3wQqlgP8aXzTKQAJRfxsPHblR8suOb9Lx9GmNwPK8=
(aus <http://al.howardknight.net/?ID=168461620500>)

Das sha256-Lock ist also im gefoldeten Teil, den der frühere Code wohl
nicht "gesehen" hat.

> <cancel.321cac1cb949...@o15.ybtra.de>

| news@weidegrund $ sm `grephistory '<cancel.321cac1cb949...@o15.ybtra.de>'` | grep Cancel
| Cancel-Key: sha256:abPGYWcXW4mnQkKSM6WoEr1KQK771IFLC9twFM31jLA=

Und der Key passt nur zum sha256-Lock.

Sollte also jetzt alles tun.

Danke!

-thh

[Peter Heirich]

Thomas Hochstein wrote:

>
>Okay. :) Mich hätte interessiert, ob mein Server jetzt auch Cancel-Locks
>und -Keys mit sha256 verarbeiten kann, aber das kann ich dann ja
>irgendwann auch mal selbst testen.

kein Problem in de.test


Date: Sat, 20 May 2023 21:16:15 -0000 (UTC)
Message-ID: <xn0o22xv...@news.heirich.name>

und dazu

Date: Sat, 20 May 2023 23:17:56 +0200
Message-ID: <cancel.xn0o...@news.heirich.name>
Lines: 10
Control:cancel <xn0o22xv...@news.heirich.name>
Newsgroups:de.test

Gruß

Peter

[Thomas Hochstein]

Peter Heirich schrieb:

> Date: Sat, 20 May 2023 21:16:15 -0000 (UTC)
> Message-ID: <xn0o22xv...@news.heirich.name>

Der hat's gar nicht bis zu mir geschafft. :)

Aber danke, Marcel hatte schon entsprechende Tests gepostet, funktioniert.

[Peter Heirich]

Thomas Hochstein wrote:

>
>Der hat's gar nicht bis zu mir geschafft. :)
>
>Aber danke, Marcel hatte schon entsprechende Tests gepostet, funktioniert.

Vermutlich mein Fehler. Ich bin mit uucp im 5 min-Takt verlinkt, war wohl
zu schnell.

Obwohl m.E. zumindest der Cancel selbst hätte rausgehen müssen. Mein
Server kann eigentlich nicht wissen, ob der Artikel in die Welt
diffundiert ist. Über poll und repost beispielsweise.

Peter

[Thomas Hochstein]

Peter Heirich schrieb:

> Vermutlich mein Fehler. Ich bin mit uucp im 5 min-Takt verlinkt, war wohl
> zu schnell.

Das würde es erklären.

> Obwohl m.E. zumindest der Cancel selbst hätte rausgehen müssen.

Ja, schon ...

| May 20 23:23:06 weidegrund innd: rejecting[perl] <cancel.xn0o...@news.heirich.name> 439 Cancel of non-existing ID <xn0o22xv...@news.heirich.name>

:)