Thunderbird 78 wartet mit einer direkten GPG-Integration auf, externe Tools wie GnuPG sind dann nicht mehr vonnöten. Eigentlich sollte die Migration bestehender Keys automatisch von der Hand gehen. Klappt das nicht, gibt es einige Tipps, die doch noch zum Erfolg führen können.
Beim automatischen Update auf Thunderbird 78.2.2 war die Ernüchterung groß – mein GnuPG-Schlüssel wollte sich partout nicht importieren lassen, eine hilfreiche Fehlermeldung gab es keine. Zwar ist u.a. für die Anbindung von Smartcards und anderer spezieller Keys auf der offiziellen Wiki-Seite ein Verfahren dokumentiert, wie Thunderbird weiterhin GPG nutzen kann, doch zumindest unter macOS funktionierte dies ebenfalls nicht, auch hier gab es keine hilfreiche Fehlermeldung.
Schnell hatte ich meinen vielleicht etwas speziellen Schlüssel in Verdacht, den ich vor vielen Jahren nach der Anleitung von Alex Cabal erstellt hatte. Wie sich herausstellte, gab es letzten Endes zwei Probleme: Zum einen unterstützt Thunderbird keine Schlüssel, deren Subkeys ein zum Hauptkey unterschiedliches Passwort haben. Zum anderen kommt der Import vermutlich mit dem zusätzlichen Subkey nicht klar.
ACHTUNG! Bitte unbedingt eine Sicherungskopie erstellen, um nicht versehentlich die Schlüssel zu löschen! Die Anwendung des untenstehenden Workarounds erfolgt auf eigene Gefahr!
Ein schneller (und damit nicht unbedingt der beste!) Workaround bestand für mich darin:
- Eine Kopie des Original-Keys inkl. Hauptschlüssel vom separaten USB-Stick auf den Computer erstellen
- Die derzeitigen Keyrings in meinem ~/.gnupg-Verzeichnis in einen Sicherungsordner verschieben
- mkdir ~/gpg-backup
- mv ~/.gnupg/pubring* ~/gpg-backup
- mv ~/.gnupg/secring* ~/gpg-backup
- mv ~/.gnupg/trustdb* ~/gpg-backup
- Da der ursprüngliche Key noch im GPGPv1-Format ist, sowohl den öffentlichen als auch den privaten Keyring in dieser Reihenfolge importieren, um ihn in das GPGv2-Format zu konvertieren:
- gpg –import /mnt/usb/pubring.gpg
- gpg –import /mnt/usb/secring.gpg
- An dieser Stelle musste ich zwei verschiedene Passwörter eingeben, da der Hauptkey ein anderes Passwort als der Subkey hatte
- In meinem Fall lieferte dann ein gpg –list-secret-keys die Ausgabe “sec” statt “sec#” für den Subkey zurück
- Jetzt im GPG-Schlüsselbund (unter macOS: GPG Keychain) ein neues Passwort für den Key setzen. Darauf achten, für Hauptkey und Subkey dieselben Passwörter zu verwenden, sonst klappt der Import in Thunderbird nicht.
- Im GPG-Schlüsselbund muss zudem das Vertrauen für den Schlüssel auf die höchste Stufe (“absolut”) gesetzt werden
- Den neuen privaten Schlüssel mittels gpg –export-secret-keys ~/secretkey.gpg exportieren
Dieser Schlüssel kann nun problemlos in Thunderbird importiert und für das entsprechende Mailkonto hinterlegt werden. Was leider nicht importiert wird, sind die bisherigen vertrauten Keys, sodass diese vorm Versand einer verschlüsselten Mail einmalig in Thunderbird gesetzt werden müssen.
Hallo Florian,
danke für die Schilderung – ich gehe aktuell davon aus, dass ich das selbe Problem unter Windows habe.
Hast du den Bug schon an Thunderbird gemeldet? Gibt es evtl. schon eine Aussicht auf Behebeung?
Gruß
Alexander
Ich hatte noch keine Zeit, zu schauen, ob der Bug schon gemeldet wurde – dass ein Key mit unterschiedlichen Passwörtern aber nicht unterstützt wird, ist bekannt, das steht auf der entsprechenden Wikiseite. Ob und wann das behoben wird, weiß ich leider nicht…
Ich fahre ebenfalls mit Unterschlüsseln und einem offline Masterkey seit 2015. Bi mir leben die Unterschlüssel auf zwei YubiKey 5 NFC. Sehr zu empfehlen um die Keys auch auf dem Smartphone zu nutzen. In meinem Fall Android.
Danke, für mich auf XUbuntu 20.04 mit einen Key aus `gpg –full-gen-key` war der Schritt `gpg –export-secret-keys > /tmp/secret.gpg`.
Schade, dass das in Thunderbird nicht ansatzweise besser gelöst oder dokumentiert wurde…
Danke für’s Feedback! :)
Wir haben ein Problem, dass seit Thunderbird 91 der öffentlich PGP-Schlüssel einer Mitarbeiterin unseres Steuerberaters nicht mehr importierbar ist. Nach dem update hat Thunderbird dieses Schlüssel einfach eliminiert, der bisher problemlos funktionierte. Kann man da etwas tun?
Achja: Win10
Ich habe mit manchen (verlängerten) Keys ein ähnliches Problem, die werden als abgelaufen markiert. Bislang hab ich noch keine Lösung gefunden – das ist ein neues Phänomen, das es so früher nicht gab.
Habe genau das gleiche Problem. Ein verlängerter Schlüssel wird nach Update auf Version 91.8.0 als abgelaufen behandelt. Auch die Version 91.8.1. hat das gleiche Problem.
Das Problem ist an mehreren Rechnern aufgetreten. An einem mit der vorigen Version funktioniert dieser Key noch prima.
Mehrere Kollegen können das hier auch unter Linux und Windows nachvollziehen, scheint also ein plattformübergreifender Bug zu sein.
Ein Zusatz zu meinem obigen Kommentar um 10:17:
Es handelt sich bei mir um meinen privaten Schlüssel dessen Ablaufdatum nach dem Update abgelaufen wäre.
Wenn ich den Schlüssel in Version 91.7.9 anschaue, sehe ich unter Zertifizierungen vier Einträge.
Zwei Mal das Datum als ich den Key erzeugt habe 4.8.2013
Dann ein Datum als ich den das erste Mal verlängert habe am 17.7.2018
Und dann noch einen Eintrag am 25.6.2020. Damals habe ich noch einmal verlängert und so weit ich mich erinnern kann auch das Passwort geändert.
Als Ablaufdatum wird der 24.6.2024 angezeigt.
Nach dem Update auf die Version 91.8.0 sind die letzten beiden Zeilen ausgetauscht. In der Spalte “Erzeugt am” steht jetzt:
4.8.2013
4.8.2013
25.6.2020
17.7.2018
Als Ablaufdatum ist vermerkt: Der Schlüssel lief am 17.7.2020 ab.
Ich gehe also davon aus, dass die letzten beiden Einträge beim Update vertauscht wurden.
Ich hab hier einen Schlüssel, bei dem das Ablaufdatum jeweils durchwechselt beim Import, aber nie das “richtige” (neue) ist.
Es gibt jetzt die Version 91.9.0. Dort scheint zumindest mein Problem behoben zu sein.
Dort ist auch ein Bugfix aufgelistet “OpenPGP integration in Thunderbird 91.8.0 and 91.8.1 did not allow SHA-1 key signatures”
Außerdem gibt es diese Info:
https://support.mozilla.org/de/kb/openpgp-unsafe-key-properties-ignored
Danke für den Hinweis! Ich kann bestätigen, dass nach Löschen und Reimport des Schlüssels des entsprechenden Empfängers wieder alles funktioniert.