Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Cancel-Lock mit sha1 oder sha256
0 views
Skip to first unread message
Peter Heirich
May 15, 2023, 9:18:58 PM5/15/23
to
Ich habe auf meinem INN Cancel-lock mit sha256 implementiert.
RFC 8315
Die Nutzung von sha1 ist nur per Draft-RFC spezifiziert.
Meine Frage ist jetzt, ob sha256 nicht kontraproduktiv war.
Die übliche Filter Software in perl ist vermutlich noch oft mit sha1
implementiert.
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.
Die Alternative in https://home.gegeweb.org/rfc8315.html ist m.E.
schwierig zu finden.
Aber Letzteres implementiert, funktioniert mit sha256, kurzer Test ok.
Die meisten Artikel nutzen noch sha1.
Also:
sha256 weiter so nutzen oder
wieder sha1 verwenden, damit ältere INN den cancel verarbeiten oder
zusätzlich 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öglich.
Meine Befürchtung ist, dass RFC8315 erst in weiteren 5-10 Jahren
weitgehend umgesetzt ist. RFC 8315 ist von Februar 2018, also jetzt gut 5
Jahre alt.
Ein count auf den newsspool mit
grep -i -r "Cancel-Lock:.*sha256:" | wc -l gab 181 aus, oft
Kombinationen von sha256+sha1
ein grep -i -r "Cancel-Lock:.*sha1:" | wc -l erbrachte 13910 Artikel
teilweise mit 2x sha1 Cancel-Lock, vermutlich User+Admin Cancel.
Meinungen?
Peter
RFC 8315
Die Nutzung von sha1 ist nur per Draft-RFC spezifiziert.
Meine Frage ist jetzt, ob sha256 nicht kontraproduktiv war.
Die übliche Filter Software in perl ist vermutlich noch oft mit sha1
implementiert.
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.
Die Alternative in https://home.gegeweb.org/rfc8315.html ist m.E.
schwierig zu finden.
Aber Letzteres implementiert, funktioniert mit sha256, kurzer Test ok.
Die meisten Artikel nutzen noch sha1.
Also:
sha256 weiter so nutzen oder
wieder sha1 verwenden, damit ältere INN den cancel verarbeiten oder
zusätzlich 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öglich.
Meine Befürchtung ist, dass RFC8315 erst in weiteren 5-10 Jahren
weitgehend umgesetzt ist. RFC 8315 ist von Februar 2018, also jetzt gut 5
Jahre alt.
Ein count auf den newsspool mit
grep -i -r "Cancel-Lock:.*sha256:" | wc -l gab 181 aus, oft
Kombinationen von sha256+sha1
ein grep -i -r "Cancel-Lock:.*sha1:" | wc -l erbrachte 13910 Artikel
teilweise mit 2x sha1 Cancel-Lock, vermutlich User+Admin Cancel.
Meinungen?
Peter
Thomas Hochstein
May 15, 2023, 10:04:32 PM5/15/23
to
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.
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
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
> 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.
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.
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.
> habe, sind mehrere cancel-locks, auch mit unterschiedlichen hash
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
0 new messages