Re: Kdwallet meldet kein gpg key

Hi Siegfried, hi.

Siegfrid Brandstätter - 27.09.25, 01:36:33 CEST:
> >> Mein Hinweise zum kompletten Restaurieren einer kompletten
> >> Sicherheitskopie bzw. für GPG zumindest vom „.gnupg“-Verzeichnis
> >> gelten weiterhin.
> 
> Problem gelöst. Ich habe einen neuen Schlüssel installiert und danach in
> Kdwallet ein neues Wallet eröffnet weil der alte immer weiterhin den
> alten Key verwenden wollte. Nun mit neuem Key plus neuem Wallet geht
> alles wie früher. Die alten Daten für den Kdwallet konnte ich
> importieren und alles läuft bestens. Wenn nicht noch was auftritt was
> momentan nicht war.

Auch ein Weg. Der durchaus gangbar ist, insofern Du den alten GPG-
Schlüssel nicht auch für andere Dinge verwendet hast.
 
> Ich bedanke mich wirklich ganz Herzlich bei allen die geholfen haben
> sehr.

> Als nächstes werde ich mir mal Kleopatra vornehmen damit ich eine
> sicherer Gpg Verwaltung habe. Falls ich das nicht falsch verstanden
> habe.

Kleopatra ist eine Anwendung mit grafischer Oberfläche für die Verwaltung 
von Zertifikaten. Im Sprachgebrauch im Kontext der Anwendung sind GPG-
Schlüssel Zertifikate, aber die Anwendung kann auch mit S/MIME-
Zertifikaten umgehen.

Eine grafische Oberfläche ersetzt jedoch nicht das grundlegende 
Verständnis der Funktion von GnuPG und von asymmetrischer Kryptographie. 
Ich weiß, dass manche Entwickler für grafische Anwendungen versuchen, PGP 
für jeden tauglich zu machen. KMail hat diesbezüglich mittlerweile den 
Autocrypt-Standard implementiert. Ich hab den nach einem Test schnell 
wieder ausgeschaltet, als ich sah, wie KMail an jede Mail nochmal den 
kompletten GPG-Schlüssel samt Signaturen angehängt hat. Ich bin der 
Überzeugung, dass solche Versuche auf Grenzen stoßen. Die Komplexität 
asymmetrischer Verschlüsselung lässt sich nicht einfach komplett 
verstecken¹. Zumindest habe ich dazu bislang keinen Ansatz gefunden, der 
wirklich für Leute geeignet ist, die die Zeit nicht investieren wollen, um 
zu verstehen, was da abläuft.

Was unklar bleibt, warum Dein offenbar rsync-basiertes Backup entweder 
unvollständig war oder Du es unvollständig oder an den falschen Ort zurück 
gesichert hast. *D.h. bei der nächsten Neu-Installation kann Dir genau das 
Gleiche wieder passieren*. Vielleicht ist diese Mailingliste nicht der 
passende Ort, das zu ergründen. Denn es bräuchte die exakten 
Befehlsaufrufe für Sichern und Restaurieren und etwaige Fehler-Ausgaben. 
Das lässt sich zwar alles anonymisieren durch das Ersetzen von Pfaden die 
Reduktion auf den für GnuPG relevanten Teil. Aber das ist ein gewisser 
Aufwand.

Am besten wäre wahrscheinlich weiterhin, dass da jemand vor Ort mal mit 
Dir drüber schaut. Ich würde das auf jeden Fall nicht so stehen lassen, 
dass offenbar etwas mit Deiner Backup-Strategie zu diesen Problem geführt 
hat, das weiterhin ungeklärt ist.


[1] Das ist so ähnlich, wie lange Zeit für den Akonadi-Dienst für die 
Verwaltung von PIM-Daten wie Mails, Kontakten und Kalenderereignissen eine 
MySQL/MariaDB-Datenbank zu verwenden. Der typische Anwender ist kein 
Datenbank-Administrator. Zum Glück kommt mittlerweile bei Neu-
Installationen das deutlich wartungsärmere (und schnellere!) SQLite3 zum 
Einsatz. Zumindest hier ist es deutlich schneller. Inwiefern daran liegt, 
wie Akonadi die Datenbank nutzt, weiß ich nicht. Firefox verwendet hier 
mehrere Dutzend SQLite3-Datenbanken. Und während zwar möglich ist, diese 
zu vakuumieren, und das manche Webseiten bei Performance-Problemen 
empfehlen, halte ich das insbesondere für Flash-basierten Speicher für 
typischerweise unnötig. Selbst bei der deutlich größeren Akonadi-Datenbank 
habe ich das bislang nicht gemacht.

Ciao,
-- 
Martin