LinuxQuestions.org - Enigmail/GnuPG issue

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - Enigmail/GnuPG issue (https://www.linuxquestions.org/questions/linux-software-2/enigmail-gnupg-issue-4175618689/)

Enigmail/GnuPG issue

Hello everyone,

having used Thunderbird (currently 52.3.0 and 52.4.0) and Enigmail (1.9.8.3 at last) since years, recently Enigmail stopped working, as it claims missing secret keys. In fact, looking at "Enigmail/Key mangement", the list is empty.

Trying to reimport pubring.gpg and secring.gpg from a backup fails with
"Error - First OpenPGP block not public key block", and Debugging Console tells us:

Code:

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: can't open '/home/someone/.gnupg/trustdb.gpg': Permission denied

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: can't open '/home/someone/.gnupg/trustdb.gpg': Permission denied

enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --no-verbose --list-packets

gpg: processing message failed: Unknown system error

Surprisingly, copying and invoking this "gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch --no-tty --status-fd 2 --no-verbose --list-packets" to a commandline works fine!

There is also fairly enough disk space on every partition.

~/.gnupg is "drwx------", and contains pubring.gpg, secring.gpg, trustdb.gpg with "-rw-------" mask. All of them belong to my user's account and group, hence rights and owner do not seem the problem here.

Consistently, "gpk -k", kgpg and even sylpheed mail all are functional, using both existing keyrings.

Then I have purged and reinstalled Thunderbird as well as Enigmail, tried the versions from Debian/testing and /stable, and also tried to install Enigmail via Addons instead of apt. No success: None of the combinations worked (in terms of Enigmail).

For testing purposes I renamed ~/.gnupg and created an empty ~/.gnupg, just to rule out the possibility of overwriting locked files. The situation did not change, it is impossible to import any key!

In my profile, I could not find any subfolders or files belonging to Enigmail, which certainly would be a good candidate to remove. There are only 15 Lines staring with 'user_pref("extensions.enigmail.(...)' in prefs.js, which all look unsuspicious.

I could not find a separate location where Enigmail would store a copy of the keys imported (maybe it tries to a non existing directory?).

Any hints and ideas for further troubleshooting welcome!

gpg (GnuPG) is version 2.1.18, libgcrypt 1.8.1, gpgagent is running. Underlying system is Debian GNU/Linux buster/sid with kernel 4.13.0-1-amd64.

Well, which userid is attempting to do this? Can you touch and thereby create a dummy file in this place? Can you rename the file, then of course rename it right back?

uid is 1000, gid also, the trivial case. It is no problem to create subdirectories and/or files in /tmp.

Therefore, could something else (execCmd, e.g.) go wrong here:

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);

Somehow it makes me think that not permissions might be the real problem, but the ability to execute an external command...

...Argh!

In /var/log/syslog there it is:

Code:

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

and indeed, disabling apparmor service by way of trial:

Code:

sudo service apparmor teardown

brings Enigmail back to normal function. Still unclear why this suddenly fails out of the box, this answered the crucial question.

...Argh!

In /var/log/syslog there it is:

Code:

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

and indeed, disabling apparmor service by way of trial:

Code:

sudo service apparmor teardown

brings Enigmail back to normal function. Still unclear why this suddenly failed out of the box, this answered the crucial question.

And the rest is astoundingly straightforward: all neccessary rules normally comes from /etc/apparmor.d/usr.bin.thunderbird, which installs out of package apparmor-profiles. For some strange reason it deinstalled from my system, and as there is no (!) dependency to other packages, you won't take notice of it.

So this issue was painful to troubleshoot, but easy to fix:

Code:

sudo apt-get install apparmor-profiles

That's all! Hopefully, this thread will help some fellows who also happen to get this package inwardly deinstalled.