• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[erledigt] (Neuen) GPG-Schlüssel akzeptieren?

wilux

Advanced Hacker
Hallo Leute,

gerade, beim Surfen, ging ein Fragefenster auf. Sinngemäß wurde ich gefragt,ob ich den/einen (neuen) GPG-Schlüssel für die Contrib-Quelle akzeptieren möchte. Passiert so was öfter/gelegentlich?

War ich zu voreilig, als ich auf Ja geklickt habe?

:???:

wilux
 
Beim surfen? Derlei wird eigentlich initiiert, wenn Du mit dem Paketmanager arbeitest, nicht einfach mal so zwischendurch. Bist Du sicher, dass nicht z.B. ein update-applet im Hintergrund arbeitet?
 

lOtz1009

Moderator
Teammitglied
Passt schon, kommt ab und an mal vor.
Sollte aber nicht beim Surfen passieren. Ich tippe mal bei dir läuft das Updaterapplet im Hintergrund und hat die Repositories aktualisiert.

Ich hatte den Signaturwechsel gestern mitbekommen.
 
OP
W

wilux

Advanced Hacker
Hallo Leute,

ja, dieses update-applet läuft bei mir. Ich verstehe es so, dass es selbstständig nach neuen Updates sucht. Hätte ich das nicht, dann müsste ich die Suche händisch anwerfen. Oder?

Danke lOtz1009 für Deinen Hinweis.

Schönen Donnerstag euch beiden.

wilux
 

/dev/null

Moderator
Teammitglied
Auch wenn ich vielleicht gleich wegen einer meiner Äußerungen "Dresche" beziehen werde, will ich noch etwas ergänzen.

wilux schrieb:
Passiert so was öfter/gelegentlich?
Im professionellen Bereich und auch bei privaten Usern, die verantwortungsbewusst mit kryptologischen Schlüsseln umgehen, haben diese immer ein maximales Gültigkeitsdatum. Dafür legt (für Behörden) das BSI bestimmte Regeln fest. Es beginnt mit täglich (!) zu wechselnden Schlüsseln (bei den entsprechenden Geheimhaltungsgraden ...) und geht von einem Jahr bei Softwaretoken für S/MIME und SSL bis hin zu 3-5 Jahren für Prozessorchipkarten.
Ich kann mir gut vorstellen, dass die Verantwortlichen der Repos ihre Signaturschlüssel auch in einem angemessenen Zeitrahmen (und selbstverständlich sofort beim kleinsten Verdacht der Kompromittierung!) wechseln. Zumindest würde ich das für gut befinden ... .

wilux schrieb:
War ich zu voreilig, als ich auf Ja geklickt habe?
Wenn du, ohne dich vorher anhand des Fingerabdruckes (Vergleich des angezeigten mit dem auf der Webseite veröffentlichten) von der Echtheit des Schlüssels zu überzeugen, einfach auf "du darfst schon" klickst, dann kannst du dir die ganze Signaturüberprüfung sparen.
Der Sinn der Signatur der Repos ist ja gerade zu verhindern, dass dir irgend ein "Wolfgang in the middle" mal schnell ein paar gefakte Updates unterschieben kann.
Also, entweder richtig oder gar nicht ... .

MfG Peter
 
OP
W

wilux

Advanced Hacker
@/dev/null

Wenn du, ohne dich vorher anhand des Fingerabdruckes (Vergleich des angezeigten mit dem auf der Webseite veröffentlichten) von der Echtheit des Schlüssels zu überzeugen, einfach auf "du darfst schon" klickst, dann kannst du dir die ganze Signaturüberprüfung sparen.
Da geb ich Dir Recht. Es ist sicher vernünftig, die Seiten mit den entsprechenden Schlüsseln in klickweite zu haben. Oder kennst Du ein besseres Verfahren (über Konsole) mit dem ich wirklich sicher den aktuellen Schlüssel erfahren kann? Mir fällt so völlig spontan nichts ein.

wilux
 

/dev/null

Moderator
Teammitglied
Den ggw. genutzten Signierschlüssel (genauer dessen Fingerprint) bekommst du ja automatisch mit.
Ob dieser wirklich zum Repo gehört, also von den Mitarbeitern usw. wirklich zum Signieren verwendet wird, kannst du nur durch den Vergleich mit dem in der Regel auf der Webseite veröffentlichten Fingerprint erkennen.
Selbst wenn du dir mit den entsprechenden Befehlen die Liste aller öffentlichen Schlüssel und Fingerprints herunterlädst, stehst du wieder vor einer Anzahl von Fingerprints, die du entweder akzeptieren oder zurückweisen kannst.

Klar könnte man dir auch wieder eine gefakte Webseite vorführen oder diese manipulieren ... .
Aber es geht bei der Signatur der Repos ja nicht nur um den erwähnten "Wolfgang" (siehe IX special 3/2010, Seite 108 ff), sondern auch darum, dass korrupte Downloads oder andere Übertragungsfehler rechtzeitig erkannt werden. Ich denke mal, das reicht in der Regel der Masse der Nutzer. (Oder vergleichen wir wirklich alle immer den Fingerprint?)

MfG Peter
 

Ganymed

Guru
Also, ´erst einmal Danke für die Sensibilisierung.
(blind bestätigen :eek:ps:)
Der Aufruf von GPG in YAST > Repositories zeigte mir bei Anwahl einzelner Schlüssel ein rot dargestelltes Ablaufdatum.

Wie muss ich jetzt vorgehen, wenn ich es richtig machen möchte?

Gruß Ganymed
 

/dev/null

Moderator
Teammitglied
Also, wenn du diese Überprüfung wirklich ensthaft betreiben willst ... . (Was ich sehr gut finde!)
- Zuerst einmal kontrollieren, ob diese abgelaufenen Schlüssel wirklich zu aktiven Repos gehören. Meist sind es nur Restbestände alter Repos.
- Dann diese abgelaufenen Schlüssel einfach löschen. (Sie schaden aber eigentlich auch nicht.)
- Wenn du jetzt nicht gerade die Signaturüberprüfung deaktiviert hast (wie hier oft beschrieben ...) dann wird beim nächsten Update der aktuelle Signaturschlüssel heruntergeladen und dir wieder die bewusste Frage nach dem Vertrauen gestellt.

Nebenbei:
Wenn zur Signatur nicht GnuPG, sondern X.509-Zertifikate verwendet werden würden, dann müssten wir nur einmal einem Trustcenter unser Vertrauen aussprechen, und das auch nur, wenn dieses nicht schon zu den allgemein vertrauenswürdigen und bereits in den Systemen implementierten zählt.

Kurios:
Schlüssel: 77B2E6003D25D3D9
Name: SuSE Security Team <security@suse.de>
Fingerabdruck: 735F2E99DFDB94C48F5AA3AEAF22F2D5
Erstellt: 06.03.1999
Der Schlüssel läuft nie ab.
(Ich weiß jetzt aber nicht, ob der noch benutzt wird!)

An dieser Stelle noch eine Ergänzung zu meinem Beitrag vom 21. Oktober 2010, 12:04:
Die erwähnten maximalen Gültigkeitsdauern für Software- und Hardwaretoken haben folgenden Hintergrund:
Der private Key auf einer evaluierten Chipkarte ist mit einer in der Regel 6-8 stelligen PIN geschützt. In Verbindung mit den drei möglichen Fehlversuchen können wir ein "Austesten" vergessen. Hier ist einfach die Gültigkeitsdauer dafür da, um auf Entwicklungen in der Kryptoanalyse (Hashverfahren und Schlüssellängen) zu reagieren.
Bei Softwaretoken besteht bei Diebstahl des Tokens die Möglichkeit, diesen ausgiebig mit einem Brute Force Angriff auszutesten. Und da ist die festgelegte Gültigkeitsdauer schon eine angemessene Frist ... .
Schlussfolgerungen für eigene GnuPG-Schlüssel bitte selbst ziehen ;-)

MfG Peter
 
Oben