Arch Linux

Ungültige PGP-Signaturen

Whitie

Hallo zusammen,
seit gestern erhalte ich beim Aktualisieren des Systems folgende Meldung:

Fehler: docker: Signatur von "Lukas Fleischer <lfleischer@lfos.de>" ist ungültig
:: Datei /var/cache/pacman/pkg/docker-1:26.1.0-1-x86_64.pkg.tar.zst ist beschädigt (Ungültiges oder beschädigtes Paket (PGP-Signatur)).
Soll die Datei entfernt werden? [J/n] j
Fehler: kwin: Signatur von "Antonio Rojas <arojas@archlinux.org>" ist ungültig
:: Datei /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst ist beschädigt (Ungültiges oder beschädigtes Paket (PGP-Signatur)).
Soll die Datei entfernt werden? [J/n] j
Fehler: Der Vorgang konnte nicht durchgeführt werden (Ungültiges oder beschädigtes Paket)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Ich habe bereits archlinux-keyring reinstalliert, mir die Schlüssel direkt vom Keyserver geholt und per pacman-key --add importiert und mehrmals den Mirror gewechselt. Nichts hat zu einem anderen Ergebnis geführt. Hat noch jemand diese Probleme? Oder kann ich noch etwas probieren?

Edit: Ich hab jetzt noch /etc/pacman.d/gnupg gelöscht und dann neu aufgebaut, wie hier beschrieben. Ändert sich aber nichts.

Viele Grüße
Whitie

brikler

Whitie Oder kann ich noch etwas probieren?

ich würde einen anderen spegelserver probieren

GerBra

Egal mit welchem Spiegelserver, teste mal folgendes und poste die Ausgaben:

pacman -Syw kwin
Das lädt das angemeckerte Paket kwin nur herunter und prüft sie Signatur. Das wird evtl. wie oben fehlschlagen, wenn du gefragt werden solltest ob du die Datei löschen willst dann sage: NEIN

gpg --homedir /etc/pacman.d/gnupg/ --fingerprint rojas

gpg --homedir /etc/pacman.d/gnupg/ --verify /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig

Beide gpg-Befehle funktionieren auch als Normal-User. Die sollten so aussehen:

$ gpg --homedir /etc/pacman.d/gnupg/ --fingerprint rojas
gpg: WARNUNG: Unsicheres Besitzverhältnis des Home-Verzeichnis `/etc/pacman.d/gnupg'
gpg: Hinweis: Die "trustdb" ist nicht schreibbar
pub   rsa4096 2014-10-21 [SC]
      9D74 DF6F 91B7 BDAB D581  5CA8 4AC5 588F 941C 2A25
uid        [vollständig] Antonio Rojas <arojas@archlinux.org>
uid        [  marginal ] Antonio Rojas <arojas@us.es>
uid        [  marginal ] Antonio Rojas <nqn1976@gmail.com>
uid        [  marginal ] Antonio Rojas <nqn76sw@gmail.com>
sub   rsa2048 2014-11-07 [S]
sub   rsa2048 2014-11-07 [E]

$ gpg --homedir /etc/pacman.d/gnupg/ --verify /mnt/s01/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig
gpg: WARNUNG: Unsicheres Besitzverhältnis des Home-Verzeichnis `/etc/pacman.d/gnupg'
gpg: die unterzeichneten Daten sind wohl in '/mnt/s01/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst'
gpg: Signatur vom Mo 22 Apr 2024 14:48:01 CEST
gpg:                mittels RSA-Schlüssel 1519D5ABA65BF6FC2B73C7567A4E76095D8A52E4
gpg: Hinweis: Die "trustdb" ist nicht schreibbar
gpg: Korrekte Signatur von "Antonio Rojas <arojas@archlinux.org>" [vollständig]
gpg:                     alias "Antonio Rojas <arojas@us.es>" [marginal]
gpg:                     alias "Antonio Rojas <nqn1976@gmail.com>" [marginal]
gpg:                     alias "Antonio Rojas <nqn76sw@gmail.com>" [marginal]

//Edit:
Vergleiche auch nochmal die Prüfsummen beider kwin-Dateien (Paket und Signatur):
sha256sum /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
Bei mir (Mein Paket-Cache liegt woanders):

$ sha256sum /mnt/s01/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
b4e363a9eb692f1e36e0615066181cd16e0481a216e66cfaf00bb5cdafa8e7ed  /mnt/s01/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst
109e1990cf167d07cb8c8f178c63a368d2e3fbed253dd163a265a28a0ab89eb1  /mnt/s01/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig

Whitie

Vielen Dank für die Antworten, hier die Ausgaben:

❯ gpg --homedir /etc/pacman.d/gnupg/ --fingerprint rojas
gpg: WARNUNG: Unsicheres Besitzverhältnis des Home-Verzeichnis `/etc/pacman.d/gnupg'
gpg: Hinweis: Die "trustdb" ist nicht schreibbar
pub   rsa4096 2014-10-21 [SC]
      9D74 DF6F 91B7 BDAB D581  5CA8 4AC5 588F 941C 2A25
uid        [vollständig] Antonio Rojas <arojas@archlinux.org>
uid        [  marginal ] Antonio Rojas <arojas@us.es>
uid        [  marginal ] Antonio Rojas <nqn1976@gmail.com>
uid        [  marginal ] Antonio Rojas <nqn76sw@gmail.com>
sub   rsa2048 2014-11-07 [S]
sub   rsa2048 2014-11-07 [E]


~
❯ gpg --homedir /etc/pacman.d/gnupg/ --verify /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig 
gpg: WARNUNG: Unsicheres Besitzverhältnis des Home-Verzeichnis `/etc/pacman.d/gnupg'
gpg: die unterzeichneten Daten sind wohl in '/var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst'
gpg: Signatur vom Mo 22 Apr 2024 14:48:01 CEST
gpg:                mittels RSA-Schlüssel 1519D5ABA65BF6FC2B73C7567A4E76095D8A52E4
gpg: Hinweis: Die "trustdb" ist nicht schreibbar
gpg: FALSCHE Signatur von "Antonio Rojas <arojas@archlinux.org>" [vollständig]

❯ sha256sum /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
42720c8e0ee3d674dc3880974c3a7f065e0872c4f5dc21664a41740c4039d498  /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst
109e1990cf167d07cb8c8f178c63a368d2e3fbed253dd163a265a28a0ab89eb1  /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig

Aus den Prüfsummen würde ich sagen, das Paket ist tatsächlich defekt. Was sagt mir aber die falsche Signatur? Die .sig Datei ist ja scheinbar in Ordnung? Ich wechsel nochmal den Mirror (habe aber bereits drei verschiedene probiert).

Viele Grüße
Whitie

Edit: Jetzt hat es funktioniert. Allerdings erst mit dem zweiten Mirror. Der Server Server = https://mirror.moson.org/arch/$repo/os/$arch scheint Probleme zu haben. Den hatte mir Reflector auch schon vorgestern ausgespuckt und es hatte nicht funktioniert.

GerBra

Whitie Aus den Prüfsummen würde ich sagen, das Paket ist tatsächlich defekt.
Whitie Edit: Jetzt hat es funktioniert. Allerdings erst mit dem zweiten Mirror.

Zumindest weißt du nun, daß das ganze Procedere bzgl. Paketprüfsummen plus Signierung funktioniert ;-)
Ich finde das sehr gut.

Spiegelserver/Mirrors:

Ich könnte mir ggf. eine Implementierung in libalpm/pacman vorstellen, die bei Erkennung eines "beschädigten" Paketes nicht nur das Löschen desselben anbietet, sondern ggf. für einen erneuten Downloadversuch zu einem nächsten aktiven Spiegelserver wechselt. Analog zum Verfahren wenn ein angefordertes Paket auf dem "ersten" Mirror nicht verfügbar ist(404). Allerdings bin ich mir auch nicht sicher, ob dieser Aufwand zur "Umgehung von Problemen bei den Mirror-Betreibern" im Verhältnis steht.
Nach Einführung der Paketsignierung sind Spiegelserver ja "wie Kraut und Rüben" in die Luft geschossen. Das kann hochprofessionell betriebene Infrastruktur sein, aber auch der "alte Server in der Garage mit ausgemusterten Festplatten, wenn eine kaputt geht nehme ich halt ne andere Alte die rumliegt - nächste Woche oder so..."
Für die Korrektheit eines Paketes spielt zum Glück die "Herkunft" keine Rolle mehr, egal ob T1-Mirror oder Garage - valide ist valide. Was IMHO auch Szenarien mit Tools wie Reflector erst möglich macht, also nicht selbst zu bestimmen/auszuwählen von welchem Mirror (oder welcher "Art" von Mirror) gerade gesynct wird.
Ich selbst bin kein Freund von Reflector-Szenarien. Ich verwende seit Jahren Spiegelserver, deren Herkunft/Domainname mir ein (subjektives¹) Gefühl von Professionalität vermittelt. Als da wären: hosteurope.de und diverse Uni/TU/FU-Mirrors. Selbst wenn ich mir die Mirrorliste jeweils "generieren" lassen würde, hätte ich wohl einen solchen Mirror (ggf. auskommentiert) an oberster Stelle, eben um solche Probleme wie deines möglichst zuverlässig zu umschiffen.

Bei jedem Mirror kann es mal Probleme geben. Hardware oder unvollständige Synchronisierung. Wir sollten dankbar sein, daß Menschen Infrastruktur(Platz und Bandbreite) uneigennützig zur Verfügung stellen!
Ein Mirrorcheck seitens Archlinux kann nicht jedes Byte von jedem Paket auf dem Mirror prüfen, sondern ggf. nur aktuelle Verfügbarkeit und allgemeine Indikatoren von Synchronisation. Tools wie Reflector basieren auf diesen Daten.

¹ Ein Mirror wie ftp.tu-chemnitz.de ist für mich subjektiv professioneller als z.B. etwas wie archlinux.windowshater-unite.de (fiktiv)
Letzteres klingt für mich eher wie Kindergarten.

tuxnix

@Whitie
Dieser Befehl ist auch komplett falsch:
sha256sum /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
Zumindest werden damit Äpfel mit Birnen verglichen. 😉

Das Problem ist ja jetzt gelöst aber richtig müsste doch eigentlich so etwas sein:
pacman-key -v /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig

pacman-key --help:
pacman-key --help | grep verify
-v, --verify Verifiziert die Datei(en), die von der/den Signatur(en) spezifiziert wurden

Der Befehl wie er oben steht:
gpg --homedir /etc/pacman.d/gnupg/ --verify /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig dürfte dazu equivalent sein.

GerBra

tuxnix Dieser Befehl ist auch komplett falsch:
sha256sum /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
Zumindest werden damit Äpfel mit Birnen verglichen. 😉

Kannst du deine Meinung erläutern?

Ich bin der Meinung, daß dieser "Befehl" - in Zusammenhang mit dem "Befehl" aus meinem vorhergehenden Post - exakt die Ursache des Problems erkennen läßt.
Ein Prüfsummenvergleich vom "richtigen" Download/Verifizieren bei mir sowohl für Paket als auch Signatur-Datei zeigt doch:

Die von seinem Mirror runtergeladene Signatur-Datei war bei ihm korrekt.
Das von seinem Mirror runtergeladene kwin-Paketarchiv eben nicht.
Ergo: hier liegt Wuff begraben ;-)

//Edit: für die jeweilige Architektur muß jedes Paketarchiv und dazugehörende Signatur-Datei exakt die gleiche Prüfsummen haben - auf jedem System. Das kann man vergleichen.
Z.B.:
test <meine_prüfsumme> == <whities_prüfsumme> ; echo $?
ergibt 1 (=falsch/ungleich), sollte 0/gleich sein.

tuxnix

GerBra Kannst du deine Meinung erläutern?

Gerne. 😉

Unterschiedliche Dateien haben unterschiedliche Prüfsummen.

$ ls -l /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
-rw-r--r-- 1 root root 10795785 22. Apr 14:48 /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      310 22. Apr 14:48 /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig

Zeigt auf einen Blick, dass die beiden Dateien schon von ihrer Größe her komplett unterschiedlich sind.
Also ist es auch kein Wunder wenn der folgende Befehl unterschiedliche Prüfsummen ausgibt.

$ sha256sum /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
b4e363a9eb692f1e36e0615066181cd16e0481a216e66cfaf00bb5cdafa8e7ed  /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst
109e1990cf167d07cb8c8f178c63a368d2e3fbed253dd163a265a28a0ab89eb1  /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig

Im pacman cache sind ohnehin nur die Pakete und ihre jeweiligen .sig Dateien vorhanden.
Um mit der Prüfsumme etwas zu überprüfen müsse es dann auch eine passende .XXsum Datei für jedes Paket geben.

Soweit jedenfalls mein Überlegung dazu.

GerBra

Du hast es leider nicht verstanden. Nochmal:

tuxnix Zeigt auf einen Blick, dass die beiden Dateien schon von ihrer Größe her komplett unterschiedlich sind.
Also ist es auch kein Wunder wenn der folgende Befehl unterschiedliche Prüfsummen ausgibt.

sha256sum /var/cache/pacman/pkg/kwin-6.0.4.1-1-x86_64.pkg.tar.zst*
Hier wird nichts "überprüft", sondern für eine oder mehrere Dateien(*) die sha256-Prüfsumme ANGEZEIGT / BERECHNET. Und natürlich haben dann sowohl kwin-6.0.4.1-1-x86_64.pkg.tar.zst als auch kwin-6.0.4.1-1-x86_64.pkg.tar.zst.sig unterschiedliche Prüfsummen.
Nur: da mein kwin-Paket den pacman-Signatur-Test besteht (Signatur und Paket passen zum Unterzeichner im Keyring) sind diese beiden Prüfsummen bei mir Maßstab.

Whitie konnte nun meine beiden Prüfsummen mit den gleichen Dateien auf seinem System vergleichen um zu ermitteln: ist entweder das Paket oder die dazugehörige Signatur-Datei beschädigt. Und wie sich rausstellte (Whitie hat das sofort kapiert <g>) ist seine von diesem Mirror runtergeladene kwin-Paket-Datei unterschiedlich gewesen. Also entweder Download-Fehler oder das Paket ist schon auf dem Mirror beschädigt. Seine mit dem Paket runtergeladene Signatur-Datei hingegen war korrekt.

tuxnix

GerBra Du hast es leider nicht verstanden.

Stimmt, ich hatte nicht kapiert, dass die von dir erstellten Prüfsummen zum Vergleich genommen wurden. Im Nachhinein muss ich zugeben, ein recht geschickter Schachzug um festzustellen woran es hier geklemmt hatte. 😉