Cancel-Lock mit sha1 oder sha256

[Thomas Hochstein]

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]

Post by Thomas Hochstein
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.

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

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

Post by Thomas Hochstein
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

Post by Thomas Hochstein
XP/Fup2 de.comm.software.newsserver

Bitte, gerne

Peter

[Michael Bäuerle]

Post by Peter Heirich

Post by Thomas Hochstein
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).

Post by Peter Heirich
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]

Post by Peter Heirich

Post by Thomas Hochstein
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.

Post by Peter Heirich
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

[Peter Heirich]

Post by Thomas Hochstein
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]

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;

[Thomas Hochstein]

Post by Peter Heirich
Kann man erfolgreiche Cancel auf Fremdservern irgendwie testen?

Im Zweifel mit einem Account dort?

[Peter Heirich]

Post by Thomas Hochstein

Post by Peter Heirich
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]

Post by Peter Heirich

Post by Peter Heirich
Kann man erfolgreiche Cancel auf Fremdservern irgendwie testen?

[...]

Post by Peter Heirich
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.

-thh

[Peter Heirich]

Post by Thomas Hochstein
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]

Post by Peter Heirich

Post by Thomas Hochstein
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.

Post by Peter Heirich
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.

Post by Peter Heirich
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.

-thh

[Marcel Logen]

[...]

Post by Thomas Hochstein

Post by Peter Heirich
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.

<***@o15.ybtra.de>
<news:***@o15.ybtra.de>

und (hoffentlich dazu passend)

Post by Thomas Hochstein

Post by Peter Heirich
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

[Marcel Logen]

[...]

Post by Marcel Logen

Post by Thomas Hochstein

Post by Peter Heirich
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.

<***@o15.ybtra.de>
<news:***@o15.ybtra.de>

und

<***@o15.ybtra.de>
<news:***@o15.ybtra.de>

Marcel

[Thomas Hochstein]

| ***@weidegrund $ grep '<***@o15.ybtra.de>' /var/log/news/news.notice
| May 20 20:20:00 weidegrund innd: SERVER cancelled <***@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.
| ***@weidegrund $ sm `grephistory '<***@o15.ybtra.de>'` | grep Cancel
| Cancel-Key: sha256:abPGYWcXW4mnQkKSM6WoEr1KQK771IFLC9twFM31jLA=

Und der Key passt nur zum sha256-Lock.

Sollte also jetzt alles tun.

Danke!

-thh

[Thomas Hochstein]

Post by Marcel Logen

Post by Thomas Hochstein
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.

und (hoffentlich dazu passend)

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

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

-thh

[Peter Heirich]

Post by Thomas Hochstein
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: <***@news.heirich.name>

und dazu

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

Gruß

Peter

[Thomas Hochstein]

Post by Peter Heirich
Date: Sat, 20 May 2023 21:16:15 -0000 (UTC)

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

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

[Peter Heirich]

Post by Thomas Hochstein
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]

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

Das würde es erklären.

Post by Peter Heirich
Obwohl m.E. zumindest der Cancel selbst hätte rausgehen müssen.

Ja, schon ...

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

:)

-thh