Discussion:
Steuernachrichten
(zu alt für eine Antwort)
Thomas Hochstein
2018-01-07 18:23:14 UTC
Permalink
[X-Post, Fup2 de.admin.news.misc]
Die DANA-Administration müsste ein neues Schlüsselpaar erzeugen
Das ist einfach ...
und den Public Key verteilen.
... und das wäre theoretisch (!) auch einfach. Man müßte ihn im
Default-control.ctl unterbringen und an passender Stelle, d.h. in
news.admin.hierarchies, d.a.n.a und dana.de, auf den Tausch hinweisen.

In der Praxis steht allerdings zu befürchten, dass eine erhebliche
Zahl von Newsservern schlicht im Autopilot läuft, weil irgendjemand
die mal eingerichtet hat, aber sie niemand mehr pflegt. Vom Rest wird
ein ganz erheblicher Teil Änderungen dieser Art nicht von sich aus
mitbekommen. Man müsste also in einer konzertierten Aktion die
Newsserverbetreiber einzeln kontaktieren.

Nicht nur, dass das aufwändig wäre; ich würde auch befürchten, dass
die Reaktion auf "wir müssten etwas am Newsserver ändern" wäre, zu
hinterfragen, warum man so etwas überhaupt noch betreibt, und statt
einer Änderung lieber den Betrieb einzustellen.

Einen prophylaktischen Schlüsseltausch halte ich daher für keine
brauchbare Vorgehensweise. Im Falle der Fälle wird man eben schauen
müssen, wie man damit umgeht.
Ich nehme allerdings an, dass die Befürchtung, dass etliche Newserver-
Betreiber das nicht tun würden, die DANA-Administration davon abgehalten
hat, den Schlüssel zu ändern.
So ist es.

(Man könnte das Für und Wider in de.admin.news.misc oder
d.c.s.newsserver diskutieren, aber ich zweifele, ob es da viel Input
gäbe.)

Grüße,
-thh

PS: Da es bei der Diskussion nicht um die Einrichtung oder Löschung
von Gruppen pp. geht, sonden um allgemeine Fragen rund um die
Adminstration - nicht nur - von de.*, leite ich mal nach
de.admin.news.misc um. Alternativ könnte man die technischen Fragen in
de.comm.software.newsserver diskutieren, aber es scheint mir nicht nur
um die bloße Technik zu gehen.
Thomas Hochstein
2018-01-07 18:23:14 UTC
Permalink
[X-Post, Fup2 de.admin.news.misc]
Oder das Problem, dass alte Versionen von PGP mit aktuellen Crypto-
Algorithmen nicht umgehen können - man hätte vermutlich nicht nur die
Länge des Schlüssels erhöht, sondern alles auf einen zeitgemäßen Stand
gebracht.
Das auch (und umgekehrt: Aktuelle Versionen von GPG können nicht mehr
mit PGP2-Schlüsseln umgehen).
Ja, auch das ist ein Problem, das möglicherweise früher oder später
einen Schlüsseltausch erforderlich machen kann.

Vor knapp zwei Jahren war das schonmal Thema in
d.c.software.newsserver, der Thread beginnt bei
<n9r9rr$3pl$***@einschein.formularfetischisten.de>, mein Beitrag, der
das Problem etwas anreißt, war
<***@landroval.ancalagon.de>.

Ich würde mich über eine technische Diskussion der Problematik sehr
freuen, gerade auch deshalb, weil ich keinen wirklich tiefen Einblick
in die hinter gpg stehende Technik habe und ebenso wenig abschätzen
kann, wie verbreitet "alte" Installationen sind, die mit neueren Keys
nicht klarkommen. Interessant wäre auch, ob es bereits eine Hierarchie
gibt, die mit einem Schlüsseltausch Erfahrung hat.

Irgendwann[tm] werden wir diese Diskussion führen müssen.

(Oder die dana-Moderation führt sie intern und macht dann das, was
dabei herauskommt - ob das ein gutes Ergebnis ist, wage ich nicht
vorherzusehen.)

Grüße,
-thh

PS: Da es bei der Diskussion nicht um die Einrichtung oder Löschung
von Gruppen pp. geht, sonden um allgemeine Fragen rund um die
Adminstration - nicht nur - von de.*, leite ich mal nach
de.admin.news.misc um. Alternativ könnte man die technischen Fragen in
de.comm.software.newsserver diskutieren, aber es scheint mir nicht nur
um die bloße Technik zu gehen.
Emil Schuster
2018-01-07 22:09:23 UTC
Permalink
Post by Thomas Hochstein
[X-Post, Fup2 de.admin.news.misc]
Oder das Problem, dass alte Versionen von PGP mit aktuellen Crypto-
Algorithmen nicht umgehen können - man hätte vermutlich nicht nur die
Länge des Schlüssels erhöht, sondern alles auf einen zeitgemäßen Stand
gebracht.
Das auch (und umgekehrt: Aktuelle Versionen von GPG können nicht mehr
mit PGP2-Schlüsseln umgehen).
Ja, auch das ist ein Problem, das möglicherweise früher oder später
einen Schlüsseltausch erforderlich machen kann.
Früher wäre mir lieber als später... Mich hat es erwischt beim Upgrade von
Jessie auf Stretch (Debian). Ich hab erst beim dana-checkgroups gemerkt,
dass Debian mal eben auf GnuPG V2 umgestellt hat, grmpf...
Thomas Hochstein
2018-01-07 23:13:20 UTC
Permalink
Post by Emil Schuster
Mich hat es erwischt beim Upgrade von
Jessie auf Stretch (Debian). Ich hab erst beim dana-checkgroups gemerkt,
dass Debian mal eben auf GnuPG V2 umgestellt hat, grmpf...
*nick*

Aber frag mal nicht, was für Probleme entstehen, wenn man gpg dazu
bekommen will, mit solchen alten Keys noch zu signieren ...
Emil Schuster
2018-01-07 23:21:02 UTC
Permalink
Post by Thomas Hochstein
Post by Emil Schuster
Mich hat es erwischt beim Upgrade von
Jessie auf Stretch (Debian). Ich hab erst beim dana-checkgroups gemerkt,
dass Debian mal eben auf GnuPG V2 umgestellt hat, grmpf...
*nick*
Aber frag mal nicht, was für Probleme entstehen, wenn man gpg dazu
bekommen will, mit solchen alten Keys noch zu signieren ...
Ja, ich beneide Dich da nicht :-)

Mein erstes Schluesselerlebnis mit dem dana-Key hatte ich schon vor vielen
Jahren bei der Umstellung von pgp auf GnuPG. Fiel mir wieder ein, als ich
auf die dana-Seite schaute:

Der PGP-Key für Control-Messages. Bei Verwendung von gpg wird empfohlen, die
User-ID "<***@dana.de>" zu entfernen, da es sonst zu Fehlern bei der
Signatur-Prüfung kommen kann.
Thomas Hochstein
2018-01-08 00:03:00 UTC
Permalink
Post by Emil Schuster
Mein erstes Schluesselerlebnis mit dem dana-Key hatte ich schon vor vielen
Jahren bei der Umstellung von pgp auf GnuPG. Fiel mir wieder ein, als ich
Der PGP-Key für Control-Messages. Bei Verwendung von gpg wird empfohlen, die
Signatur-Prüfung kommen kann.
Ooooh ja. - Das ist meiner Erinnerung nach aber mittlerweile gefixt.

*nachguck*

Oh, erst 2014?! <https://inn.eyrie.org/trac/changeset/9621>

Ich dachte, das wäre schon viel länger her ...

-thh
David Seppi
2018-01-08 09:40:10 UTC
Permalink
Post by Emil Schuster
Mich hat es erwischt beim Upgrade von
Jessie auf Stretch (Debian). Ich hab erst beim dana-checkgroups gemerkt,
dass Debian mal eben auf GnuPG V2 umgestellt hat, grmpf...
Haja ... Ich hab das erst gemerkt, als tinews.pl nicht mehr mit gpg
signieren konnte und dann meinte den aktuell laufenden RfD unsigniert
nach dana posten zu müssen. Natürlich ohne jegliche Fehlermeldung.
Mir fiel das erst auf, als ich in Tin die Signatur prüfen wollte.
--
David Seppi
1220 Wien
Emil Schuster
2018-01-08 13:03:32 UTC
Permalink
Post by David Seppi
Post by Emil Schuster
Mich hat es erwischt beim Upgrade von
Jessie auf Stretch (Debian). Ich hab erst beim dana-checkgroups gemerkt,
dass Debian mal eben auf GnuPG V2 umgestellt hat, grmpf...
Haja ... Ich hab das erst gemerkt, als tinews.pl nicht mehr mit gpg
signieren konnte und dann meinte den aktuell laufenden RfD unsigniert
nach dana posten zu müssen. Natürlich ohne jegliche Fehlermeldung.
Mir fiel das erst auf, als ich in Tin die Signatur prüfen wollte.
Tja... Ich beneide die Moderation nicht um die Entscheidung, ob mal ein
neuer dana-Key fällig wäre. Wenigstens tut sich in der Gruppenliste
praktisch nichts mehr, das wird ja jetzt direkt zum Vorteil :-(

U.a. der BIG8-Key ist ja auch so ein altes Teil. Ob der sich wohl noch mal
ändert?
Michael Bäuerle
2018-01-08 13:51:38 UTC
Permalink
Post by Emil Schuster
Post by David Seppi
Post by Emil Schuster
Mich hat es erwischt beim Upgrade von
Jessie auf Stretch (Debian). Ich hab erst beim dana-checkgroups gemerkt,
dass Debian mal eben auf GnuPG V2 umgestellt hat, grmpf...
Haja ... Ich hab das erst gemerkt, als tinews.pl nicht mehr mit gpg
signieren konnte und dann meinte den aktuell laufenden RfD unsigniert
nach dana posten zu müssen. Natürlich ohne jegliche Fehlermeldung.
Mir fiel das erst auf, als ich in Tin die Signatur prüfen wollte.
Tja... Ich beneide die Moderation nicht um die Entscheidung, ob mal ein
neuer dana-Key fällig wäre. Wenigstens tut sich in der Gruppenliste
praktisch nichts mehr, das wird ja jetzt direkt zum Vorteil :-(
U.a. der BIG8-Key ist ja auch so ein altes Teil. Ob der sich wohl noch mal
ändert?
Schön wäre, wenn man die Möglichkeit hätte mit 2 Keys zu signieren (so,
dass es abwärtskompatibel ist). Dann würden alte Maschinen nicht außen
vor bleiben und aktuelle Maschinen könnten den neuen Key zur Prüfung
verwenden.
Emil Schuster
2018-01-08 15:20:03 UTC
Permalink
Post by Michael Bäuerle
Schön wäre, wenn man die Möglichkeit hätte mit 2 Keys zu signieren (so,
dass es abwärtskompatibel ist). Dann würden alte Maschinen nicht außen
vor bleiben und aktuelle Maschinen könnten den neuen Key zur Prüfung
verwenden.
Du bringst mich da auf eine Idee... Was spräche dagegen, wenn die Moderation
einen neuen Key generieren und bis auf weiteres Steuernachrichten zwei mal
versenden würde, einmal alt und einmal neu signiert?
Thomas Hochstein
2018-01-08 20:28:37 UTC
Permalink
Post by Emil Schuster
Du bringst mich da auf eine Idee...
Ungefähr zwei Jahre nach mir? ;)
Post by Emil Schuster
Was spräche dagegen, wenn die Moderation
einen neuen Key generieren und bis auf weiteres Steuernachrichten zwei mal
versenden würde, einmal alt und einmal neu signiert?
Das wäre m.E. der einzig gangbare Weg, der aber ebenfalls Nachteile
hat: "bis auf weiteres" heißt vermutlich "das nächste Jahrzehnt oder
bis Usenet entgültig das Licht ausgeht, je nachdem, was zuerst
passiert", und vermutlich führt dann jeder dieser "doppelten"
checkgroups zu einer Fehlermeldung (entweder der eine oder der
andere).

Das ist auch noch kein Königsweg.

-thh
Emil Schuster
2018-01-08 21:15:32 UTC
Permalink
Post by Thomas Hochstein
Post by Emil Schuster
Du bringst mich da auf eine Idee...
Ungefähr zwei Jahre nach mir? ;)
Ich wusste nicht, dass es da schon mal eine Diskussion gab.
Post by Thomas Hochstein
Post by Emil Schuster
Was spräche dagegen, wenn die Moderation
einen neuen Key generieren und bis auf weiteres Steuernachrichten zwei
mal versenden würde, einmal alt und einmal neu signiert?
Das wäre m.E. der einzig gangbare Weg, der aber ebenfalls Nachteile
hat: "bis auf weiteres" heißt vermutlich "das nächste Jahrzehnt oder
bis Usenet entgültig das Licht ausgeht, je nachdem, was zuerst
passiert", und vermutlich führt dann jeder dieser "doppelten"
checkgroups zu einer Fehlermeldung (entweder der eine oder der
andere).
Das ist auch noch kein Königsweg.
Schon klar. Ich habe bewusst "bis auf weiteres" geschrieben... Na gut,
ignoriere ich halt künftig Steuernachrichten. Viel ändern wird sich eh nicht
mehr.
Thomas Hochstein
2018-01-08 23:24:13 UTC
Permalink
Post by Emil Schuster
Post by Thomas Hochstein
Post by Emil Schuster
Du bringst mich da auf eine Idee...
Ungefähr zwei Jahre nach mir? ;)
Ich wusste nicht, dass es da schon mal eine Diskussion gab.
Diskutiert worden ist es tatsächlich nicht, aber ich hatte genau
Deinen Gedanken (und den in
Post by Emil Schuster
Na gut, ignoriere ich halt künftig Steuernachrichten. Viel ändern wird sich eh nicht
mehr.
Sorry, ich hatte das Problem nicht richtig erfasst ... :-/ Ich ging
davon aus, dass es nur einer passenden Konfiguration bedarf, die
Verifikation aber nicht unmöglich ist.

Du hast jedoch Recht: derzeit lassen sich die Steuernachrichten unter
Debian Stretchn nicht prüfen. Das liegt allerdings nicht primär daran,
dass Debian auf GnuPG 2 umgestellt hat, denn die alten Versionen (gpg1
und gpgv1) stehen weiter zur Verfügung. Vielmehr haben die Signaturen
als Digest noch MD5, und das "frisst" gpgv 1.4.18 (Debian Jessie) zwar
noch, aber gpgv 1.4.21 (Debien Stretch) nicht mehr.

Ich denke aber, *dieses* Problem lässt sich (um den Preis des Verlusts
der Kompatibilität zu pgp 2.6.2) lösen.

Grüße,
-thh
Thomas Hochstein
2018-01-09 00:41:26 UTC
Permalink
Post by Thomas Hochstein
Ich denke aber, *dieses* Problem lässt sich (um den Preis des Verlusts
der Kompatibilität zu pgp 2.6.2) lösen.
Hm, so einfach ist es offenbar leider nicht. :-/

Ich habe das Ergebnis meiner Test und Recherchen und die damit
verbundenen Fragestellungen in de.comm.software.newsserver gepostet
(<***@meneldor.ancalagon.de>).

Grüße,
-thh
Marc Haber
2018-01-09 14:30:59 UTC
Permalink
Post by Thomas Hochstein
und vermutlich führt dann jeder dieser "doppelten"
checkgroups zu einer Fehlermeldung (entweder der eine oder der
andere).
Bei Newsservern im Autopilotmodus würde das eventuell Aufmerksamkeit
erregen.

IIRC kann ich doch Kontrollnachrichten, die mit einem bestimmten Key
signiert sind, ignorieren, anhand einer Blacklist von Keys, oder? Wenn
es das Feature nicht gibt, gehört das schnellstens implementiert.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Thomas Hochstein
2018-01-09 16:39:26 UTC
Permalink
Post by Marc Haber
Post by Thomas Hochstein
und vermutlich führt dann jeder dieser "doppelten"
checkgroups zu einer Fehlermeldung (entweder der eine oder der
andere).
Bei Newsservern im Autopilotmodus würde das eventuell Aufmerksamkeit
erregen.
Möglich, ja.
Post by Marc Haber
IIRC kann ich doch Kontrollnachrichten, die mit einem bestimmten Key
signiert sind, ignorieren, anhand einer Blacklist von Keys, oder?
Das wäre mir jetzt völlig neu.

Man kann sich natürlich im control.ctl was zusammenbauen, aber es wäre
mir jetzt neu, dass man da (bei identischem Absender) gezielt
unterschiedliche Signaturen unterschiedlich behandeln kann.
Post by Marc Haber
Wenn es das Feature nicht gibt, gehört das schnellstens
implementiert.
Wenn man darauf warten will, kann man auch darauf warten, dass Russ
die Verwendung von gpg1 statt gpgv in pgpverify einbaut (was geplant
ist, aber wer weiß, wann?) oder ein altes gpg (oder direkt pgp)
Installieren und für die Steuernachrichten verwenden.

-thh

Thomas Hochstein
2018-01-08 20:28:37 UTC
Permalink
Post by Emil Schuster
U.a. der BIG8-Key ist ja auch so ein altes Teil. Ob der sich wohl noch mal
ändert?
Die BIG8 sind, was das hierarchy management betrifft, ziemlich tot,
insbesondere seit dem frühen Tod von Alexander Bartolich. Es gibt
praktisch keine Verfahren mehr, die Webseiten sind nicht aktuell, und
das Management Board hat, soweit ich sehe, eine ganze Reihe seiner
turnusmäßigen Nachwahlen verpasst.

Es würde mich überraschen, wenn man dann mal eben den Key wechseln
würde.
Jörg Tewes
2018-01-07 20:19:11 UTC
Permalink
Post by Thomas Hochstein
[X-Post, Fup2 de.admin.news.misc]
Die DANA-Administration müsste ein neues Schlüsselpaar erzeugen
Das ist einfach ...
und den Public Key verteilen.
... und das wäre theoretisch (!) auch einfach. Man müßte ihn im
Default-control.ctl unterbringen und an passender Stelle, d.h. in
news.admin.hierarchies, d.a.n.a und dana.de, auf den Tausch hinweisen.
In der Praxis steht allerdings zu befürchten, dass eine erhebliche
Zahl von Newsservern schlicht im Autopilot läuft, weil irgendjemand
die mal eingerichtet hat, aber sie niemand mehr pflegt. Vom Rest wird
ein ganz erheblicher Teil Änderungen dieser Art nicht von sich aus
mitbekommen. Man müsste also in einer konzertierten Aktion die
Newsserverbetreiber einzeln kontaktieren.
Nicht nur, dass das aufwändig wäre; ich würde auch befürchten, dass
die Reaktion auf "wir müssten etwas am Newsserver ändern" wäre, zu
hinterfragen, warum man so etwas überhaupt noch betreibt, und statt
einer Änderung lieber den Betrieb einzustellen.
Was vermutlich bei diesen Newsservern nicht die schlechteste Idee
wäre. Ein Newsserver der nur im Autopilot läuft ist, u.U. auch nicht
so wirklich auf dem Stand der Dinge was den Gruppenbestand angeht.
Post by Thomas Hochstein
Einen prophylaktischen Schlüsseltausch halte ich daher für keine
brauchbare Vorgehensweise. Im Falle der Fälle wird man eben schauen
müssen, wie man damit umgeht.
Zustimm.


Bye Jörg
--
"I am the right hand of vengeance. And the boot that is gonna kick
your sorry ass all the way back to earth. I'm death incarnate and
the last living thingthat you are ever going to see. God sent me!!"
(Ivanova in "Between the Darkness and the Light")
Thomas Hochstein
2018-01-07 23:13:20 UTC
Permalink
Post by Jörg Tewes
Ein Newsserver der nur im Autopilot läuft ist, u.U. auch nicht
so wirklich auf dem Stand der Dinge was den Gruppenbestand angeht.
Wenn alles so läuft, wie es soll vermutlich schon, weil er signierte
Steuernachrichten eben ausführt.
Jörg Tewes
2018-01-08 10:12:56 UTC
Permalink
Post by Thomas Hochstein
Post by Jörg Tewes
Ein Newsserver der nur im Autopilot läuft ist, u.U. auch nicht
so wirklich auf dem Stand der Dinge was den Gruppenbestand angeht.
Wenn alles so läuft, wie es soll vermutlich schon, weil er signierte
Steuernachrichten eben ausführt.
Wenn alles läuft wie es soll, würde es keine Server mit Gruppen geben
die schon längst gelöscht sind, wie schon bemerkt.


Bye Jörg
--
No Linux inside
David Seppi
2018-01-08 09:33:50 UTC
Permalink
Post by Jörg Tewes
Was vermutlich bei diesen Newsservern nicht die schlechteste Idee
wäre. Ein Newsserver der nur im Autopilot läuft ist, u.U. auch nicht
so wirklich auf dem Stand der Dinge was den Gruppenbestand angeht.
... und das abuse management dürfte auch nicht vorhanden sein.
--
David Seppi
1220 Wien
Jörg Tewes
2018-01-08 10:16:29 UTC
Permalink
Post by David Seppi
Post by Jörg Tewes
Was vermutlich bei diesen Newsservern nicht die schlechteste Idee
wäre. Ein Newsserver der nur im Autopilot läuft ist, u.U. auch nicht
so wirklich auf dem Stand der Dinge was den Gruppenbestand angeht.
... und das abuse management dürfte auch nicht vorhanden sein.
Das ist imho sowieso nur bei sehr wenigen vorhanden.


Bye Jörg
--
"That does seem to be the rule, doesn't it? Analyze the problem,
choose whichever strategy makes least sense, and do it."
(Dr. Lazarenn, "Confessions and Lamentations")
Christian Schumacher
2018-01-07 20:22:37 UTC
Permalink
Post by Thomas Hochstein
In der Praxis steht allerdings zu befürchten, dass eine erhebliche
Zahl von Newsservern schlicht im Autopilot läuft, weil irgendjemand
die mal eingerichtet hat, aber sie niemand mehr pflegt.
Ich wage die These, dass die Menge der nicht gepflegten
"Autopilot"-Newsserver einen hohen Deckungsgrad mit denen aufweist, die
Steuernachrichten gar nicht umsetzen.
Letzteres hätte ja bedeutet, dass sie das System überhaupt einmal
entsprechend hätten konfigurieren müssen und dann würden sie ja
zumindest aktuell noch synchron sein, was den de.*-Gruppenbestand angeht.
Insofern ist es in Bezug auf diese Server schon fast wurscht, ob man
einen neuen Key einführt oder nicht.
Post by Thomas Hochstein
Vom Rest wird
ein ganz erheblicher Teil Änderungen dieser Art nicht von sich aus
mitbekommen. Man müsste also in einer konzertierten Aktion die
Newsserverbetreiber einzeln kontaktieren.
Es würde unabhängig des Anlasses sicher nicht schaden, einen
Kommunikationskanal zu möglichst vielen Betreibern zu haben, der nicht
nur aus Postings in admin-Gruppen besteht.

Gruß
Christian
Loading...