Enigmail importiert und kennt keine Schlüssel mehr

Hallo beisammen,

seit Jahren nutze ich Thunderbird & Enigmail unter Linux (Distribution Debian, Level testing). Seit einigen Tagen treten plötzlich Fehler auf wie "gpg: Entschlüsselung fehlgeschlagen: Kein geheimer Schlüssel (...)", und tatsächlich fehlen in der Schlüsselverwaltung sowohl die öffentlichen als auch meine privaten Schlüssel.

Installiert ist gpg2 (gpg (GnuPG) 2.1.18, libgcrypt 1.8.1), mit dem Verzeichnis ~/.gnupg, darin u.a. die Schlüsselringe pubring.gpg, secring.gpg, trustdb.gpg, sowohl das Verzeichnis als auch die Dateien sämtlich mit der korrekten Rechtemaske "drwx------"/"-rw-------" sowie meiner Benutzerkennung und -gruppe gehörend.

Damit entfällt eine der häufigsten und naheliegenden Ursachen, nämlich falsche Eigentums- oder Rechteeinstellung. Im übrigen ist auch reichlich Festplattenplatz frei (vollgelaufene Partitionen sind immerhin auch eine gern lange übersehene Fehlerquelle). Daß seitens gpg alles in Ordnung ist, beleget auch die Ausgabe von "gpg -k" (listet korrekt die privaten Schlüssel) als auch die Tatsache, daß sowohl kgpg als auch ein testweise installiertes sylpheed (schlankes Reintext-E-Mail-Programm mit eingebauter gpg-Unterstützung) einwandfrei funktionieren. Daraufhin habe ich Thunderbird und Enigmail über die Paketverwaltung (apt purge) deinstalliert und neu installiert, in einem zweiten Anlauf auch die ältere Versionen aus "stable" installiert, in einem dritten und vierten Anlauf Enigmail aus der Paketverwaltung jeweils weggelassen und das passende Enigmail über die AddOn-Verwaltung Thunderbirds installiert. In sämtlichen Fällen hat sich am Problem nichts geändert. Ein versionsabhängiger Bug scheint mir daher auch unwahrscheinlich zu sein.

Testweise habe ich auch das ~/.gnupg-Verzeichnis umbenannt und ein leeres ~/.gnupg erstellt, um auszuschließen, daß der Fehler eventuell durch den Versuch entsteht, bestehende und von kgpg (o.a.) gesperrte Schlüsselringdateien mit sich selbst zu überschreiben. Auch dann war kein Import möglich.

Nachfolgend eine bemerkenswerte Zitate aus der Enigmail-Fehlerkonsole, zunächst das Ergebnis eines Importversuchs eines Schlüsselrings:

Code:

---

gpg: Schlüsselblockhilfsmittel`/tmp/enigmail_import/keyring': Keine Berechtigung
gpg: key EB810A42B4AB5CDE: 1 Beglaubigung wegen fehlendem Schlüssel nicht geprüft
gpg: kein schreibbarer Schlüsselbund gefunden: Nicht gefunden

gpg: processing message failed: Unbekannter Systemfehler

enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --with-fingerprint --fixed-list-mode --with-colons --list-keys
gpg: Fatal: '/home/jemand/.gnupg/trustdb.gpg' kann nicht geöffnet werden: Keine Berechtigung
enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --with-fingerprint --fixed-list-mode --with-colons --list-secret-keys
gpg: Fatal: '/home/jemand/.gnupg/trustdb.gpg' kann nicht geöffnet werden: Keine Berechtigung

---

Das Überraschende daran ist, daß die letzten beiden Kommandos, manuell auf eine Shell kopiert, einwandfrei die öffentlichen und privaten Schlüssel listen! Nachdem Thunderbird und Enigmail ja auch mit derselben Benutzerkennung laufen, ist ein Rechteproblem hier ausgeschlossen. Irgendetwas im Zusammenwirken von Enigmail und gpg mißlingt offenbar.


Hat jemand noch weitere Ideen, was hier sonst noch klemmen oder was ich sonst noch versuchen könnte?

hm, die Erfahrung sagt, wenn ein Linux-System behauptet

Code:

---

gpg: Schlüsselblockhilfsmittel`/tmp/enigmail_import/keyring': Keine Berechtigung

---

hat es meistens recht.

Kein Zweifel! Nur warum ist das so?

Wie geschildert, ~/.gnupg und sein Inhalt sind in Ordnung, was Owner und Permissions angeht. In /tmp darf der User auch Dateien anlegen, an Platz dafür scheitert es auch nicht, und ich kann mir nicht vorstellen, daß Thunderbird&Enigmail Unterprozesse starten, die als anderer Benutzer laufen (wie denn auch).

Gestern und heute habe ich stundenlang das Web durchsucht, dabei ist mir aufgefallen, daß nach Abzug all der zahlreichen "chown/chmod-hat-geholfen!"-Threads noch ein Häuflein übrigbleibt, die alle das "Unbekannter Systemfehler", "nicht schreibbarer Schlüsselbund" usw. gemeinsam haben. Nur leider hat keine dieser wenigen Geschichten bisher ein Happy End.

Ich möchte hinzufügen: Fehlermeldungen können manchmal äußerst irreführend sein. So wäre es denkbar, daß Enigmail versucht, in irgendeinen unmöglichen Pfad zu schreiben - nur wie läßt sich das prüfen und wieder in die Spur bringen? Weiß jemand, wo ein gesundes Enigmail seine importierten Schlüsselringe hinspeichert? Nach ~/.gnupg wohl nicht, denn da liegen sie ja schon, und sind für alle anderen Anwendungen auch normal benutzbar...

Einen Unterordner von Enigmail in meinem Thunderbird-Profil, den ich dann auch gerne manuell vor einer Reinstallation gelöscht hätte, gibt es auch nicht.

... und die konkrete Berechtigung der konkret angegeben Datei inkl. dem Pfad dahin hast Du geprüft?

... weil - aus eigener Erfahrung - wenn man manche Dinge mal für mehrere Nutzer macht hat man da evtl. bei solchen copy-paste-Aktionen plötzlich Verzeichnisse da, die "eigentlich sonst nie da sind" und die gehören plötzlich einem anderen Benutzer...

Hmm, "die konkrete Berechtigung der konkret angegeben Datei inkl. dem Pfad dahin"?
Der Pfad dahin ist mein home, und in .gnugp sehen wir:

Code:

---

50862166  4 drwx------  4 phaseolus phaseolus  4096 Nov 30 14:35 .
50860252  20 drwxr-xr-x 195 phaseolus phaseolus  20480 Nov 30 16:49 ..
50862365  4 -rw-------  1 phaseolus phaseolus    459 Jul 20  2016 gpg-agent.conf
50862524  12 -rw-------  1 phaseolus phaseolus  8431 Nov 30 15:50 gpg.conf
50862363  4 -rw-------  1 phaseolus phaseolus    272 Sep  3  2015 gpgsm.conf
50862290 712 -rw-------  1 phaseolus phaseolus 727082 Sep 11 14:55 pubring.gpg
50862292  4 -rw-------  1 phaseolus phaseolus    600 Nov 30 12:14 random_seed
50862528  12 -rw-------  1 phaseolus phaseolus  12036 Feb  3  2015 secring.gpg
50862294  4 -rw-------  1 phaseolus phaseolus  3960 Sep 11 14:55 trustdb.gpg

---

(Und wenn das NICHT passen würde, könnten kgpg und sylpheed auch nicht damit arbeiten!)

Inzwischen habe ich mit "thunderbird --ProfileManager" noch ein weiteres, fabrikneues Profil angelegt. Auch hier versagt schon der Einrichtungsdialog von Enigmail wie beschrieben.

Der Sand im Getriebe muß irgendwo ganz anderes herkommen...

... und was ist mit

Code:

---

/tmp/enigmail_import/keyring

---

?

Ein Verzeichnis /tmp/enigmail und ein Unterverzeichnis oder eine Datei "keyring" gibt es nicht, läßt sich aber problemlos mit den Rechten des Benutzers (also auch denen von TB/Enigmail) erstellen:

Code:

---

phaseolus@beanbox:/tmp$ mkdir -p /tmp/enigmail_import/
phaseolus@beanbox:/tmp$ touch  /tmp/enigmail_import/keyring
phaseolus@beanbox:/tmp$ ll  /tmp/enigmail_import/keyring
6815863 0 -rw-r--r-- 1 phaseolus phaseolus 0 Dez  1 09:54 /tmp/enigmail_import/keyring

---

Daran kann es also auch nicht liegen. (Und überhaupt: auf einem anderen Rechner mit funktionierendem Thunderbird gibt es das /tmp/enigmail_import auch nicht, und es wird bei einem Import eines Schlüssels allenfalls temporär angelegt, zu Gesicht bekam ich es jedenfalls nicht.)

Ich habe mittlerweile den Verdacht, Enigmail (offenbar Javascript?) kann vielleicht keine Prozesse starten kann. Die nicht gestarteten Prozesse führen dann natürlich auch die gewünschten Dateioperationen "fehlerhaft" aus...?

Code:

---

getKeyListFromKeyBlock: function(keyBlockStr, errorMsgObj) {
    var ret = [];

    let keyTypeObj = this.getKeyFileType(keyBlockStr);

    if (keyTypeObj.keyType === KEY_BLOCK_UNKNOWN) {
      errorMsgObj.value = EnigmailLocale.getString("notFirstBlock");
      return ret;
    }

    if (keyTypeObj.keyType === KEY_BLOCK_REVOCATION) {
      this.importRevocationCert(keyBlockStr, keyTypeObj.packetStr);
      errorMsgObj.value = "";
      return ret;
    }

    const tempDir = EnigmailFiles.createTempSubDir("enigmail_import", true);
    const tempPath = EnigmailFiles.getFilePath(tempDir);
    const args = EnigmailGpg.getStandardArgs(true).concat([
      "--import",
      "--trustdb", tempPath + "/trustdb",
      "--no-default-keyring", "--keyring", tempPath + "/keyring"
    ]);

    const exitCodeObj = {};
    const statusMsgObj = {};

    EnigmailExecution.execCmd(EnigmailGpg.agentPath, args, keyBlockStr, exitCodeObj, {}, statusMsgObj, errorMsgObj);

---

Das scheint mir die kritische Stelle zu sein. Bin aber kein Entwickler und überfragt damit, (a) wie man das gezielt testen könnte und (b) welche Systembestandteile (libs) alles daran beteiligt sind, die vielleicht in einer unpassenden Versionskombination vorliegen. (Auch wenn das, schon klar, "eigentlich" dank Paketverwaltung nicht passieren dürfte. Der Unterschied zwischen Theorie und Praxis ist in der Praxis aber oftmals größer als in der Theorie ,-) )

Um erst mal pauschal sicherzustellen, keine beschädigte Anwendungs-, System- oder Bibliotheksdateien zu haben, lasse ich mal ein

Code:

---

    apt-get install --reinstall  $(dpkg --get-selections | grep install | grep -v deinstall | sed 's/\t.*//g')

---

laufen, um alle installierten Pakete abermals zu installieren...

Im /var/log/syslog fand ich nun den Schuldigen:

Code:

---

... apparmor="DENIED" operation="open" profile="thunderbird" ...

---

und tatsächlich: nach

Code:

---

sudo service apparmor teardown

---

funktioniert Enigmail wieder wie es sich gehört. Jetzt gilt es nur noch eine sauberere Lösung zu finden als AppArmor ganz zu deaktivieren...

... ok:
Alles Nötige steckt in /etc/apparmor.d/usr.bin.thunderbird, und das wiederum kommt aus dem Paket apparmor-profiles, welches aus welchem Grund auch immer nicht (mehr) installiert war. Das Thunderbird-Paket führt es leider nicht als Abhängigkeit, d.h. ein Verlust des apparmor-profiles-Pakets kann, wie wir gesehen haben, ebenso schwer zu entdecken sein wie leicht zu korrigieren:

Code:

---

sudo apt-get install apparmor-profiles

---

Das wars! Und die oder der nächste findet vielleicht diesen Thread und erspart sich etwas Lebenszeit :o)