Discussion:
pgpverify mit gpg1 (was: GnuPG 1.4 + GnuPG 2.* mit update-alternatives betreiben)
(zu alt für eine Antwort)
Thomas Hochstein
2018-01-20 12:57:38 UTC
Permalink
Der INN verwendet das Programm gpgv und da kriegt man es anscheinend nicht
hin. Russ Allberry kennt das Problem und hat es auf seiner TODO-Liste,
"Yeah, you need gpg1 --verify --allow-weak-digest-algos. I haven't fixed
this in pgpverify yet; that needs to be done. That seems to work so far,
but the right solution is probably to switch to new keys, with all that
entails."
<http://winterlamm.szaf.org/~thh/inn/Add-support-for-gpg-in-addition-to-gpgv.patch>
ist ein Patch (naja, das was "git --format-patch" erzeugt) gegen
pgpverify 1.29.

Versuch das doch mal statt des "mitgelieferten" pgpverify [2], und
setz $gpg im Script auf "/usr/bin/gpg1". Bei mir funktioniert das mit
dem aktuellen Checkgroups und scheint keine Seiteneffekte zu haben.

Wäre schön, wenn das noch jemand testet.
Er ist auch der Meinung, dass man neue Keys generieren sollte, aber...
Ja, ich glaube auch, dass das unausweichlich sein wird, aber das
möchte ich nicht übers Knie brechen.

Grüße,
-thh

[1] Diskussionen in Testgruppen sind eine entsetzliche Unsitte, weil
sie dort niemand erwartet, oft nicht einmal archiviert und gewisslich
nicht wiederfindet.

[2] Kann man ja in pgpverify.ORIG oder so umbenennen.
Emil Schuster
2018-01-20 23:26:45 UTC
Permalink
Post by Thomas Hochstein
<http://winterlamm.szaf.org/~thh/inn/Add-support-for-gpg-in-addition-to-gpgv.patch>
ist ein Patch (naja, das was "git --format-patch" erzeugt) gegen
pgpverify 1.29.
Versuch das doch mal statt des "mitgelieferten" pgpverify [2], und
setz $gpg im Script auf "/usr/bin/gpg1". Bei mir funktioniert das mit
dem aktuellen Checkgroups und scheint keine Seiteneffekte zu haben.
Wäre schön, wenn das noch jemand testet.
Ich habe das mal mit den letzten vier checkgroups gemacht, das sind BIG8,
de, hr und hun. Das sind alles alte Keys bis auf TLD hr, das ist ein neuer
Key.

Im Prinzip ist alles prima, Tests siehe weiter unten. Ich habe allerdings
ausserhalb INN im Testmodus gearbeitet, d.h. die Stunde der Wahrheit kommt
erst beim scharf schalten.

Die Patch-Version meckert halt alle Keys an, weil gpg ja schärfer prüft als
gpgv. Ist das im Patch-Returncode berücksichtigt? Wenn ja, werde ich es
scharf schalten. Kaputtgehen kann ja nichts, ausser dass ich noch mehr
Fehlermeldungen bekomme.

Ausserdem hat gpg1 eine Config in /var/spool/news/.gnupg/gpg.conf angelegt,
aber das stört nicht.

Hier die Tests:

BIG8 Original:

[GNUPG:] NEWSIG
gpgv: Signatur vom Mo 15 Jan 2018 17:00:01 CET
gpgv: mittels RSA-Schlüssel C25D3AD3B88DA9C1
[GNUPG:] ERRSIG C25D3AD3B88DA9C1 1 8 01 1516032001 9
[GNUPG:] NO_PUBKEY C25D3AD3B88DA9C1
gpgv: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

BIG8 Patch:

gpg: Unterschrift vom Mo 15 Jan 2018 17:00:01 CET mittels RSA-Schl?ssel ID
B88DA9C1
[GNUPG:] SIG_ID mh7nm43iDXV2PLA8UzD2UjGVOuM 2018-01-15 1516032001
[GNUPG:] GOODSIG C25D3AD3B88DA9C1 news.announce.newgroups
gpg: Korrekte Unterschrift von "news.announce.newgroups"
[GNUPG:] VALIDSIG F53558D35564101407C69553136FD407 2018-01-15 1516032001 0 3
0 1 8 01 F53558D35564101407C69553136FD407
[GNUPG:] TRUST_UNDEFINED
gpg: WARNUNG: Dieser Schl?ssel tr?gt keine vertrauensw?rdige Signatur!
gpg: Es gibt keinen Hinweis, dass die Signatur wirklich dem
vorgeblichen Besitzer geh?rt.
Haupt-Fingerabdruck = F5 35 58 D3 55 64 10 14 07 C6 95 53 13 6F D4 07
news.announce.newgroups

TLD de Original:

[GNUPG:] NEWSIG
gpgv: Signatur vom Di 02 Jan 2018 01:12:13 CET
gpgv: mittels RSA-Schlüssel 7536EAB5D3033C99
[GNUPG:] ERRSIG 7536EAB5D3033C99 1 1 01 1514851933 9
[GNUPG:] NO_PUBKEY 7536EAB5D3033C99
gpgv: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

TLD de Patch:

gpg: Unterschrift vom Di 02 Jan 2018 01:12:13 CET mittels RSA-Schl?ssel ID
D3033C99
gpg: WARNUNG: Die Verwendung des Hashverfahrens MD5 ist nicht ratsam
gpg: Siehe https://gnupg.org/faq/weak-digest-algos.html f?r weitere Infos
[GNUPG:] SIG_ID tz+ybBcax8RA3kWI/qg3riFgtAY 2018-01-02 1514851933
[GNUPG:] GOODSIG 7536EAB5D3033C99 de.admin.news.announce
gpg: Korrekte Unterschrift von "de.admin.news.announce"
[GNUPG:] VALIDSIG 5BB05288BF55194F667DC2AE16262825 2018-01-02 1514851933 0 3
0 1 1 01 5BB05288BF55194F667DC2AE16262825
[GNUPG:] TRUST_UNDEFINED
gpg: WARNUNG: Dieser Schl?ssel tr?gt keine vertrauensw?rdige Signatur!
gpg: Es gibt keinen Hinweis, dass die Signatur wirklich dem
vorgeblichen Besitzer geh?rt.
Haupt-Fingerabdruck = 5B B0 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25
de.admin.news.announce

TLD hr Original: (Das ist ein neuer Key)

[GNUPG:] NEWSIG
gpgv: Signatur vom Mi 17 Jan 2018 13:05:01 CET
gpgv: mittels DSA-Schlüssel 71921BA3ED63AD9A
[GNUPG:] KEY_CONSIDERED 0EE574FB1C407ADB0AACA52F71921BA3ED63AD9A 0
[GNUPG:] SIG_ID +wflk+KWr3aFYGf6GdDbE2jdZPQ 2018-01-17 1516190701
[GNUPG:] KEY_CONSIDERED 0EE574FB1C407ADB0AACA52F71921BA3ED63AD9A 0
[GNUPG:] GOODSIG 71921BA3ED63AD9A ***@carnet.hr
gpgv: Korrekte Signatur von "***@carnet.hr"
[GNUPG:] VALIDSIG 0EE574FB1C407ADB0AACA52F71921BA3ED63AD9A 2018-01-17
1516190701 0 3 0 17 2 00 0EE574FB1C407ADB0AACA52F71921BA3ED63AD9A
***@carnet.hr

TLD hr Patch:

gpg: Unterschrift vom Mi 17 Jan 2018 13:05:01 CET mittels DSA-Schl?ssel ID
ED63AD9A
[GNUPG:] SIG_ID +wflk+KWr3aFYGf6GdDbE2jdZPQ 2018-01-17 1516190701
[GNUPG:] GOODSIG 71921BA3ED63AD9A ***@carnet.hr
gpg: Korrekte Unterschrift von "***@carnet.hr"
[GNUPG:] VALIDSIG 0EE574FB1C407ADB0AACA52F71921BA3ED63AD9A 2018-01-17
1516190701 0 3 0 17 2 00 0EE574FB1C407ADB0AACA52F71921BA3ED63AD9A
[GNUPG:] TRUST_UNDEFINED
gpg: WARNUNG: Dieser Schl?ssel tr?gt keine vertrauensw?rdige Signatur!
gpg: Es gibt keinen Hinweis, dass die Signatur wirklich dem
vorgeblichen Besitzer geh?rt.
Haupt-Fingerabdruck = 0EE5 74FB 1C40 7ADB 0AAC A52F 7192 1BA3 ED63 AD9A
***@carnet.hr

TLD hun Original:

[GNUPG:] NEWSIG
gpgv: Signatur vom Di 02 Jan 2018 06:59:25 CET
gpgv: mittels RSA-Schlüssel 0C0156C45D144299
[GNUPG:] ERRSIG 0C0156C45D144299 1 1 01 1514872765 9
[GNUPG:] NO_PUBKEY 0C0156C45D144299
gpgv: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

TLD hun Patch:

gpg: Unterschrift vom Di 02 Jan 2018 06:59:25 CET mittels RSA-Schl?ssel ID
5D144299
gpg: WARNUNG: Die Verwendung des Hashverfahrens MD5 ist nicht ratsam
gpg: Siehe https://gnupg.org/faq/weak-digest-algos.html f?r weitere Infos
[GNUPG:] SIG_ID BtiKjk58P9uyIEpXmgxMoB8xk9s 2018-01-02 1514872765
[GNUPG:] GOODSIG 0C0156C45D144299 hun.admin.news
gpg: Korrekte Unterschrift von "hun.admin.news"
[GNUPG:] VALIDSIG 122DDCFDF17C8B41B04AF1E613A5E30E 2018-01-02 1514872765 0 3
0 1 1 01 122DDCFDF17C8B41B04AF1E613A5E30E
[GNUPG:] TRUST_UNDEFINED
gpg: WARNUNG: Dieser Schl?ssel tr?gt keine vertrauensw?rdige Signatur!
gpg: Es gibt keinen Hinweis, dass die Signatur wirklich dem
vorgeblichen Besitzer geh?rt.
Haupt-Fingerabdruck = 12 2D DC FD F1 7C 8B 41 B0 4A F1 E6 13 A5 E3 0E
hun.admin.news
Post by Thomas Hochstein
[1] Diskussionen in Testgruppen sind eine entsetzliche Unsitte, weil
sie dort niemand erwartet, oft nicht einmal archiviert und gewisslich
nicht wiederfindet.
Hast ja recht, aber so ist das Usenet halt heuzutage... Siehe deinen
aktuellen RfD. In dem Thread geht es um alles mögliche, nur nicht um den RfD
:-(
Emil Schuster
2018-01-21 10:26:49 UTC
Permalink
Post by Emil Schuster
Die Patch-Version meckert halt alle Keys an, weil gpg ja schärfer prüft
als gpgv. Ist das im Patch-Returncode berücksichtigt? Wenn ja, werde ich
es scharf schalten. Kaputtgehen kann ja nichts, ausser dass ich noch mehr
Fehlermeldungen bekomme.
Man sollte nicht spät nachts solche Tests machen :-(

Ich habe mir das Script jetzt mal angesehen. Alles in Ordnung und vergesse
die deutschen Texte in meinem Test... Ich habe den Patch jetzt scharf
geschaltet.

Ich nehme an, dass in der endgültigen Version die neue Variable $gpg in
INN::Config und innshellvars.pl aufgenommen wird?
Thomas Hochstein
2018-01-21 11:26:16 UTC
Permalink
Post by Emil Schuster
Ich habe mir das Script jetzt mal angesehen. Alles in Ordnung und vergesse
die deutschen Texte in meinem Test... Ich habe den Patch jetzt scharf
geschaltet.
Ich bei mir auch. Warten wir's mal ab.
Post by Emil Schuster
Ich nehme an, dass in der endgültigen Version die neue Variable $gpg in
INN::Config und innshellvars.pl aufgenommen wird?
So dachte ich mir das, ja. Mal sehen, was Russ und ggf. Julien meinen.

Grüße,
-thh
--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>
Emil Schuster
2018-02-04 06:02:03 UTC
Permalink
Post by Thomas Hochstein
Post by Emil Schuster
Ich habe mir das Script jetzt mal angesehen. Alles in Ordnung und vergesse
die deutschen Texte in meinem Test... Ich habe den Patch jetzt scharf
geschaltet.
Ich bei mir auch. Warten wir's mal ab.
Control Channel:
Sender newgroup rmgroup Other Bad PGP DoIt OK
***@dana.de 0 0 1 0 1 1

Funktioniert, wie erwartet :-) Danke noch für den Patch!

Gruß,
Emil
Thomas Hochstein
2018-02-04 12:55:21 UTC
Permalink
Post by Emil Schuster
Funktioniert, wie erwartet :-) Danke noch für den Patch!
Danke, und: gerne!
Thomas Hochstein
2018-01-21 11:25:16 UTC
Permalink
Post by Emil Schuster
Post by Thomas Hochstein
<http://winterlamm.szaf.org/~thh/inn/Add-support-for-gpg-in-addition-to-gpgv.patch>
ist ein Patch (naja, das was "git --format-patch" erzeugt) gegen
pgpverify 1.29.
Warum einfach, wenn es auch kompliziert geht ...

Einfacher ist sicherlich
<http://winterlamm.szaf.org/~thh/inn/pgpverify>; das ist das "fertige"
Script für Debian Stretch und braucht nur noch "apt install gpg1".
Post by Emil Schuster
Im Prinzip ist alles prima, Tests siehe weiter unten. Ich habe allerdings
ausserhalb INN im Testmodus gearbeitet, d.h. die Stunde der Wahrheit kommt
erst beim scharf schalten.
Die Patch-Version meckert halt alle Keys an, weil gpg ja schärfer prüft als
gpgv. Ist das im Patch-Returncode berücksichtigt? Wenn ja, werde ich es
scharf schalten. Kaputtgehen kann ja nichts, ausser dass ich noch mehr
Fehlermeldungen bekomme.
Du hattest ja schon geschrieben, dass es abends etwas spät war. ;)

Falls es noch jemand testen möchte - der einfachste Weg dürfte dieser
sein:
| sm `grephistory '<checkgroups-2018-***@dana.de>'` | /usr/lib/news/bin/pgpverify ; echo $?

Message-ID des Checkgroups und Pfad zum pgpcerify entsprechend
anpassen; der Exit-Status sollte "0" sein.
Post by Emil Schuster
Ausserdem hat gpg1 eine Config in /var/spool/news/.gnupg/gpg.conf angelegt,
aber das stört nicht.
Hier nicht. *kopfkratz* Mag aber daran liegen, dass ich das unter
root, nicht unter news getestet habe.
Post by Emil Schuster
Post by Thomas Hochstein
[1] Diskussionen in Testgruppen sind eine entsetzliche Unsitte, weil
sie dort niemand erwartet, oft nicht einmal archiviert und gewisslich
nicht wiederfindet.
Hast ja recht, aber so ist das Usenet halt heuzutage... Siehe deinen
aktuellen RfD. In dem Thread geht es um alles mögliche, nur nicht um den RfD
: -(
Du sagst es. *seufz*

(Aber ab und an darf ich über den Verfall der Sitten mal schimpfen.
;))

Danke fürs Testen!

-thh
--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>
Thomas Hochstein
2018-02-11 21:43:54 UTC
Permalink
Post by Thomas Hochstein
Post by Thomas Hochstein
<http://winterlamm.szaf.org/~thh/inn/Add-support-for-gpg-in-addition-to-gpgv.patch>
ist ein Patch (naja, das was "git --format-patch" erzeugt) gegen
pgpverify 1.29.
Einfacher ist sicherlich
<http://winterlamm.szaf.org/~thh/inn/pgpverify>; das ist das "fertige"
Script für Debian Stretch und braucht nur noch "apt install gpg1".
Der Patch ist nun sowohl in pgpcontrol 2.6 [1] als auch im aktuellen
INN-Trunk [2] enthalten und soll mit INN 2.6.2 released werden.

[1] <https://www.eyrie.org/~eagle/journal/2018-02/003.html>
[2] <https://inn.eyrie.org/trac/changeset/10242>

Grüße,
-thh
--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>
Martin Burmester
2019-07-18 15:43:07 UTC
Permalink
Hallo,
Post by Thomas Hochstein
Post by Thomas Hochstein
Post by Thomas Hochstein
<http://winterlamm.szaf.org/~thh/inn/Add-support-for-gpg-in-addition-to-gpgv.patch>
ist ein Patch (naja, das was "git --format-patch" erzeugt) gegen
pgpverify 1.29.
Einfacher ist sicherlich
<http://winterlamm.szaf.org/~thh/inn/pgpverify>; das ist das "fertige"
Script für Debian Stretch und braucht nur noch "apt install gpg1".
Der Patch ist nun sowohl in pgpcontrol 2.6 [1] als auch im aktuellen
INN-Trunk [2] enthalten und soll mit INN 2.6.2 released werden.
erst mal sorry für den Antwort auf den alten Thread, aber gibt es hier
schon erfahrungen mit dem update auf Debian buster? Kann man hier
einfach die mitgelieferte Version verwenden? Gibt es neue Probleme?

Grüße,
Martin
Emil Schuster
2019-07-18 16:14:29 UTC
Permalink
Post by Martin Burmester
Hallo,
Post by Thomas Hochstein
Der Patch ist nun sowohl in pgpcontrol 2.6 [1] als auch im aktuellen
INN-Trunk [2] enthalten und soll mit INN 2.6.2 released werden.
erst mal sorry für den Antwort auf den alten Thread, aber gibt es hier
schon erfahrungen mit dem update auf Debian buster? Kann man hier
einfach die mitgelieferte Version verwenden? Gibt es neue Probleme?
Grüße,
Martin
Ja, kann man. Hier läuft INN 2.6.3 mit gpg1 unter Buster problemlos. Für
pgpverify ist kein Patch mehr erforderlich.
--
Emil
Thomas Hochstein
2020-10-03 13:44:16 UTC
Permalink
Post by Emil Schuster
Ja, kann man. Hier läuft INN 2.6.3 mit gpg1 unter Buster problemlos.
Für pgpverify ist kein Patch mehr erforderlich.
Und nachdem mein Gedächtnis offenbar wie ein Sieb ist - wenn man noch
Debian Stretch laufen hat (oder wie ich erst im Mai das Upgrade auf
Stretch gemacht hat) und sich wundert, dass pgpverify nicht (mehr) tut,
kann man das so reparieren:

# gepatchte Version von pgpverify installieren
cd /usr/lib/news/bin
mv pgpverify pgpverify.ORIG
wget http://winterlamm.szaf.org/~thh/inn/pgpverify
chmod 755 pgpverify
# gpg1 installieren
apt install gnupg1

*seufz*

-thh

PS: Die Einzelheiten finden sich "weiter oben" im alten Thread,
"Einsprungpunkte" für Archive:
<***@meneldor.ancalagon.de>
<***@meneldor.ancalagon.de>

Loading...