SDB:YOU oder RPM melden Probleme beim Verifizieren der Paketsignaturen

aus openSUSE, der freien Wissensdatenbank

Symptom

YaST Online Update (YOU) meldet, dass es ein Paket nicht installieren kann, da die Signatur nicht verifiziert werden kann, oder rpm meldet NOKEY.

Zum Beispiel meldet YOU

ERROR(You:RPM has invalid signature.)

oder rpm liefert Meldungen wie

warning: /tmp/man-pages-1.67-1.10.noarch.rpm: V3 DSA signature: NOKEY, key ID 9c800aca

Hintergrund: Paketsignaturen

Das in SUSE LINUX verwendete RPM-Paketmanagementsystem benutzt mit GNU Privacy Guard [wikipedia] implementierte digitale Signaturen [wikipedia], um dafür zu sorgen, dass eine RPM-Paketdatei von einer vertrauenswürdigen Quelle (Novell/SUSE) erzeugt wurde und dass sie nicht manipuliert oder verändert wurde (entweder unabsichtlich durch Fehler bei der Datenübertragung während des Downloads oder absichtlich durch eine übelwollende Partei).

Wenn Sie mehr über das RPM-Paketmanagementsystem und seine Anwendung von digitalen Signaturen wissen wollen, empfehlen wir das Buch Maximum RPM.

Mögliche Ursachen

Die häufigste Ursache für Probleme im Zusammenhang mit RPM-Signaturen sind Datenübertragungsfehler beim Download. Diese Datenübertragungsfehler können vielfältige Ursachen haben, z.B. einfache Übertragungsfehler oder ein inhaltsverändernder Proxy (z.B. eine Anti-Virus-Software hält eine RPM-Datei irrtümlich für eine infizierte Datei). In diesem Artikel wird dieser Fall nicht behandelt. Wir setzen voraus, dass Sie einen Datenübertragungsfehler bereits ausgeschlossen haben.

In diesem Fall liegt die Ursache tiefer: das RPM-Paketmanagementsystem kann vergessen haben, welchen öffentlichen Schlüsseln es für Paketsignaturen vertrauen kann.

Hintergrund: RPM-Versionen

Wie es bei Linux-Software oft der Fall ist, wird auch das RPM-Paketmanagementsystem ständig weiterentwickelt. Es gibt daher wichtige Unterschiede bei den Befehlen, die in RPM Version 3 (verwendet in SLES8, SLSS und SLOX) zum Umgang mit Schlüsseln und Signaturen verfügbar sind, und denen, die in RPM Version 4 verfügbar sind (verwendet in SLES9 und SUSE LINUX 9.3). Stellen Sie fest, welche RPM-Version Ihr System benutzt (gegebenenfalls mit rpm -q rpm prüfen) und gehen Sie vor, wie in den entsprechenden Abschnitten unten beschrieben.

Analyse der Ursache (RPM Version 4)

Das RPM-System sollte die Schlüssel kennen, die von Novell/SUSE zum Signieren von SUSE-RPM-Paketen verwendet werden. Dies kann durch Untersuchung der Ausgabe des Befehls

rpm -qa 'gpg-pubkey*' | sort

geschehen. In SLES9 sollte die Ausgabe wie folgt lauten:

gpg-pubkey-3d25d3d9-36e12d04
gpg-pubkey-9c800aca-40d8063e

In SUSE 9.3 enthält die Ausgabe einen weiteren Schlüssel:

gpg-pubkey-0dfb3188-41ed929b
gpg-pubkey-3d25d3d9-36e12d04
gpg-pubkey-9c800aca-40d8063e

Wenn das RPM-System nicht in Ordnung ist, wird eine andere Ausgabe erzeugt, die eventuell auch leer sein kann.

Lösung (RPM Version 4)

Importieren Sie erneut die von Novell/SUSE verwendeten öffentlichen Schlüssel von einem vertrauenswürdigen Medium:

• Mounten Sie die erste CD Ihrer SLES-Installationmedien unter /mnt.
• Führen Sie

  rpm --import /mnt/gpg-pubkey-3d25d3d9-36e12d04.asc

  aus.
• Führen Sie

  rpm --import /mnt/gpg-pubkey-9c800aca-39eef481.asc

  aus.
• Falls /mnt/gpg-pubkey-0dfb3188-41ed929b.asc existiert, führen Sie den Befehl

  rpm --import /mnt/gpg-pubkey-0dfb3188-41ed929b.asc

  aus.
• Überprüfen Sie, ob RPM die Schlüssel korrekt importiert hat, indem Sie

  rpm -qa 'gpg-pubkey*' | sort

  ausführen, und kontrollieren Sie, ob die Ausgabe nun der oben beschriebenen erwarteten Ausgabe entsprechen.
• Wenn die rpm-Zeile nicht diese Ausgabe erzeugt (z.B. wenn die Ausgabe leer ist), führen Sie das Kommando

  rpm --rebuilddb

  aus und wiederholen dann den Schlüsselimport (rpm --import ..) mit anschließender Überprüfung.

Analyse der Ursache (RPM Version 3)

Auch in diesem Fall sollte das RPM-System zwei Schlüssel kennen, die von Novell/SUSE zum Signieren von SUSE-RPM-Paketen verwendet werden. Im Gegensatz zu RPM Version 4, bei der es Befehle zum direkten Umgang mit Schlüsseln gibt, hat RPM Version 3 noch keine solchen Befehle. Aus diesem Grunde sind die zu benutzenden Befehle ziemlich andersartig.

Falls die Schlüssel für RPM funktionieren, sollte der Befehl

gpg --no-options --no-default-keyring --keyring /usr/lib/rpm/gnupg/pubring.gpg --list-keys

beide Schlüssel in einer Ausgabe aufführen, die der folgenden ähnelt:

/usr/lib/rpm/gnupg/pubring.gpg
------------------------------
pub 1024D/C58B7883 2002-09-03 UnitedLinux Package Signing Key
sub 2048g/797B62F9 2002-09-03 [expires: 2007-09-02]
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team

pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key
sub 2048g/8495160C 2000-10-19 [expires: 2006-02-12]

Wenn das RPM-System nicht in Ordnung ist, wird eine andere Ausgabe erzeugt, die eventuell auch leer sein kann.

Lösung (RPM Version 3)

Importieren Sie erneut die von Novell/SUSE verwendeten öffentlichen Schlüssel von einem vertrauenswürdigen Medium:

• Binden Sie die erste CD der Installationsmedien unter /mnt ein.
• Führen Sie den Befehl

  gpg --no-options --no-default-keyring --keyring /usr/lib/rpm/gnupg/pubring.gpg --import /mnt/pubring.gpg

  aus.
• Führen Sie den Befehl

  gpg --no-options --no-default-keyring --keyring /usr/lib/rpm/gnupg/pubring.gpg --list-keys

  erneut aus und kontrollieren Sie, ob die Schlüssel jetzt in dem von RPM verwendeten Schlüsselbund importiert sind.
• Falls eine Fehlermeldung wie fatal: /usr/lib/rpm/gnupg/trustdb.gpg: invalid trustdb angezeigt wird, führen Sie

  rm -f /usr/lib/rpm/gnupg/trustdb.gpg

  aus, wiederholen den Schlüsselimport und kontrollieren das Ergebnis.