smart: Probleme mit key-ids

[gropiuskalle]

Huhu!

Mein smart hat Probleme, die key-ids zu importieren. Das Holen von Updateinformationen und neuen Paketen funktioniert nach wie vor, aber dann kommt diese Meldung:

Übermittle Transaktion ...
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 26d830e9
Trying to import the key f7df9a4426d830e9 from pgp.mit.edu...
gpg: requesting key 26D830E9 from hkp server pgp.mit.edu
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
FEHLER!: gpg failed to import keyid f7df9a4426d830e9, please make sure that gpg is installed, that the keyserver pgp.mit.edu is working and that the package /var/lib/smart/packages/libesd0-0.2.38-34.6.i586.rpm has a valid signature.
FEHLER!: libesd0-0.2.38-34.6.i586.rpm: public key not available

Ich habe /var/lib/smart komplett neu eingerichtet (mirrors, channel etc.), kein Unterschied.

Edit:

smart config --set rpm-check-signatures=false

Sorgt zwar dafür, dass die Pakete ohne signature-check installiert werden, aber das möchte ich nicht als Dauerlösung betrachten.

Haben andere smart / SuSE10.3-Nutzer vielleicht ähnliche Probleme oder ist das eine systeminterne Kiste?

Edit #2: Scheint doch nur einzelne channels zu betreffen, zumindest konnte ich eben Pakete aus bestimmten Repos installieren - muss das morgen mal etwas eingrenzen, Erfahrungsberichte sind dennoch erwünscht.

 

[Gast1]

*Fingerheb*

Betrifft auch openSUSE 10.2/smart und liegt wohl am Keyserver.

Versucht man die Keys von Hand von pgp.mit.edu zu importieren, so sind diese auf obigem Server (noch) nicht verfügbar.

Mal ein wenig abwarten.

"Würgarond"

Im Unterordner "repodata" die Datei repomd.xml.key herunterladen und mit "rpm --import repomd.xml.key" importieren (müsste auch direkt mit "rpm --import *URL_zum_Repository*/repodata/repomd.xml.key" gehen).

Greetz,

RM

 

[gropiuskalle]

Im Unterordner "repodata" die Datei repomd.xml.key herunterladen und mit "rpm --import repomd.xml.key" importieren (müsste auch direkt mit "rpm --import *URL_zum_Repository*/repodata/repomd.xml.key" gehen).

Bei über dreißig channeln mache ich lieber das hier:

Mal ein wenig abwarten.

Wird sich schon einrenken. Aber danke für den Hinweis, dass es nicht nur mich betrifft...

 

[devilz]

Von der openSuSE ML

You wonder why zypper or YaST do ask you to accept new keys for
some repositories atm ?
Please read this mail in this case.

The repositories on opensuse.org below the

http://download.opensuse.org/repositories/

directory get currently new GPG keys which are used to sign the repository
meta data and the packages. The reason behind this is to increase the security
for you and your system. Repositories inside of this directory are created by
the openSUSE build service packagers. Everybody can go to

http://build.opensuse.org

and get at least an own home:<login> project where you can build and publish
packages. But also all other projects have different owners, this means
people who have write permissions there.

As a consequence of this openess of the build service, users should have
the possibility to decide whom to trust and whom not. This is easy possible
by adding or not adding/removing repositories.
However, rpm and package managers do use gpg keys to support users in this
approach. These tools use them to verify that a certain repository and each
package does indeed come from a certain person or group.

In the past, all build service repositories were signed with the same key.
This means that a user was able to allow or disallow repositories, but the
the tools did not help or even checked this. This approach was therefore not
save against attacks.

We use from now on own keys per top-level project. Users can decide to accept
certain keys or not. Packagers will get an API interface to manage these keys
in near future to some degree.

These keys are auto generated by the build service and report to come from

KDE OBS Project <KDE@build.opensuse.org>

or

home:adrianSuSE OBS Project <home:adrianSuSE@build.opensuse.org>

for example.

In case you are not sure, if you can trust a certain project, you should log
into the build service via

http://build.opensuse.org

and look at the list of persons who are part of this project. (Yes, a system
which makes this more transparent for the End User is in our plan).

I hope this helps
adrian

PS: There was a bug, which caused failures when using rpm checking a
signature. This will be solved by rebuilding these packages. YaST and zypper
are using gpg and had never this problem.

 

[Gast1]

Langsam wirds etwas nervig:

smart upgrade
Lade Zwischenspeicher...
Update Zwischenspeicher...              ###################################################### [100%]

Berechne Vorgang ...

Erneuere Pakete (2):
  mozilla-xulrunner181-1.8.1.11-2.3@i586            mozilla-xulrunner181-devel-1.8.1.11-2.3@i586

10.1MB an Paketdateien sind benötigt.

Änderungen anwenden? (J/n) :

Übermittle Transaktion ...
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 766da614
Trying to import the key 026b47f3766da614 from pgp.mit.edu...
gpg: requesting key 766DA614 from hkp server pgp.mit.edu

Und dieses mal will es auch nach der händischen Installation des Keys nicht.

Ich versuche mal einen Keyserver zu finden, wo diese Keys schon verfügbar sind.

//Edit:

Kein Wunder, der Key ist im Repository noch nicht aktualisiert worden.

//Edit2:

http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x766DA614&exact=on

Public Key Server -- Error

No matching keys in database

Maaaaaah .. verdammt.

Greetz,

RM

//Edit, die 3.

Da das Ganze Verfahren scheinbar recht langsam von Statten geht und die Keys irgendwie dem default-Keyserver weiterhin unbekannt sind, hier eine Methode, wie man als einzelner smart-User der gesamten Community helfen kann.

Am Beispiel des Mozilla-Repositories (ich verwende kgpg)

Der aktuelle Key 0x766DA614 befindet sich noch nicht im Repository für 10.2/10.3, wohl aber schon im Repository für SuSE-Factory.

ftp://ftp5.gwdg.de/pub/opensuse/repositories/mozilla/openSUSE_10.2/repodata

ftp://ftp5.gwdg.de/pub/opensuse/repositories/mozilla/SUSE_Factory/repodata

(Man achte auf das jeweilige Datum)

Das Vorgehen war nun sehr einfach.

1. Kgpg öffnen

2. Schlüssel importieren => Datei

ftp://ftp5.gwdg.de/pub/opensuse/repositories/mozilla/SUSE_Factory/repodata/repomd.xml.key

3. Einstellungen => Schlüsselserver => pgp.mit.edu als Standard setzen.

4. Auf den importierten Schlüssel => Rechtsklick => Öffentlichen Schlüsel exportieren => Standardschlüsselserver

Und ein paar Minuten später konnte smart den Schlüssel von pgp.mit.edu importieren.

# smart reinstall mozilla-xulrunner181-devel-1.8.1.11-2.3
Lade Zwischenspeicher...
Update Zwischenspeicher...              ###################################################### [100%]

Berechne Vorgang ...

Installiere Pakete (1):
  mozilla-xulrunner181-devel-1.8.1.11-2.3@i586

3.6MB an Paketdateien sind benötigt.19.5MB wird benutzt.

Änderungen anwenden? (J/n) :

Übermittle Transaktion ...
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 766da614
Trying to import the key 026b47f3766da614 from pgp.mit.edu...
gpg: requesting key 766DA614 from hkp server pgp.mit.edu
gpg: key 766DA614: "mozilla OBS Project <mozilla[at]build.opensuse.org>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

[B]The above GPG key has been imported successfully.[/B]
It is required to install this package:

        mozilla-xulrunner181-devel-1.8.1.11-2.3.i586.rpm

Do you want to trust this key forever?

You must verify the below fingerprint before answering.
pub   1024D/766DA614 2008-01-22 [expires: 2010-04-01]
      Key fingerprint = AAA5 3190 5D82 9BDC BE4D  5169 026B 47F3 766D A614
uid                  mozilla OBS Project <mozilla[at]build.opensuse.org>


If you answer "Yes" all other packages signed with this key will be installed automatically. (j/N) : j

Bereite vor ...                         ###################################################### [  0%]
   1:Installiere mozilla-xulrunner181.. ###################################################### [100%]

Voilà.


http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x766DA614&exact=on

Search results for '0x766da614'
Type bits/keyID Date User ID
pub 1024D/766DA614 2008-01-22 mozilla OBS Project <mozilla[at]build.opensuse.org>

Kleine Ursache => Große Wirkung und jeder kann mithelfen, indem er dieses Verfahren auf die Keys anwendet, die ihm smart als fehlend auswirft. Das Prinzip ist dabei immer das selbe, man benötigt die _aktuellste_ Datei repomd.xml.key im Verzeichnis repodata, einfach die verschiedenen Repositories durchsuchen, am wahrscheinlichsten wird man den aktuellsten key unter SuSE-Factory finden.


Greetz,

RM

 

[gropiuskalle]

Wie gesagt, über 30 channel, da fang' ich gleich mal mit an...

Erstmal Kaffee.

Edit:

Klappt absolut ohne Probleme, und smart arbeitet wieder wie gewohnt. Danke für den Tipp, R_M (zumal Keys exportieren gut für's Karma ist).