Thunderbird/Enigmail denied executing Split-GPG

I’m currently getting an AppArmor error like this whenever I view a message in Thunderbird:

Apr 22 13:34:51 host kernel: [ 2477.096917] audit: type=1400 audit(1492868091.674:16): apparmor=“DENIED” operation=“exec” profile=“thunderbird” name="/usr/bin/qubes-gpg-client-wrapper" pid=2846 comm=“thunderbird” requested_mask=“x” denied_mask=“x” fsuid=1000 ouid=0

This is accompanied by the following errors in Enigmail:

Enigmail initialization failed.

You are using GnuPG version , which is not up to date anymore. Enigmail recommends GnuPG version 2.0 or newer; please upgrade your GnuPG installation, or Enigmail will not work.

Enigmail: Error in accessing Enigmail service

In order to use Enigmail, GnuPG is required. If you did not install GnuPG yet, the easiest way to do this is using the “Setup Wizard” button below.

Enigmail is configured to use Qubes Split-GPG. It appears that this error started occurring when Icedove was renamed to Thunderbird in Debian.

Not certain if this is a bug in Qubes, Whonix, or Debian, but figured I’d ask here first.

1 Like

Yeah, this is really hard in this case to figure out.

  • Qubes bug -> yes -> because that same issue would happen in a Qubes Debian template

  • Thunderbird (at least in Debian stretch) as per Debian default is now shipping its own AppArmor profile, which does now allow access to /usr/bin/qubes-gpg-client-wrapper

  • Could therefore also be a Debian bug and ideally fixed in Debian?

  • Or Qubes could offer the https://github.com/Whonix/apparmor-profile-icedove package.

  • Whonix bug -> yes, as well -> Since Whonix offers https://github.com/Whonix/apparmor-profile-icedove which will be only fixed in Whonix 14 (or in Whonix 13 only through manual package upgrade / manually getting the new profile).

Indeed, it’s an interesting bug to attribute.

What would be the recommended course of action for affected users to take? Wait for an update? (At the moment I can’t read or send encrypted email.) Disable AppArmor? (I’d prefer to keep AppArmor enabled…) Apply some kind of manual change? (My experience with AppArmor is pretty minimal, so it’s not obvious to me what manual band-aid fix might be feasible.)

You could be reporting this bug against all projects involved, Qubes and
Debian, since it applies to them as well. Qubes should accept the bug,
not sure what Debian will say, but their answer will be very good to
know nonetheless.

Waiting for an update would be too long, I guess. Due to time
restraints, I won’t be able to give this priority.

Disabling AppArmor would be one easy but unfortunate option.

Apply the manual change is possible but not simple without documentation
how to do that. Figuring that out makes you more like a developer than a

Maybe the profile folder change during the re-branding is related (?). See:


With this update, the Icedove packages are de-branded back to the official Mozilla branding. With the removing of the Debian branding the packages are also renamed back to the official names used by Mozilla.

The Thunderbird package is using a different default profile folder, the default profile folder is now ‘$(HOME)/.thunderbird’. The users profile folder, that was used in Icedove, will get migrated to the new profile folder on the first start, that can take a little bit more time.

Very much so yes.

If I were to download this file, and save it in the path /etc/apparmor.d/local/usr.bin.thunderbird in the TemplateVM that I use for Thunderbird, would that be likely to fix the issue? Would doing so be likely to break anything else?

Can do. You still need to active the change using aa-enforce.

1 Like

Saving that file to /etc/apparmor.d/local/usr.bin.thunderbird and then running sudo aa-enforce usr.bin.thunderbird in the TemplateVM seems to have fixed it for me.

Would it be useful if I submitted a PR to that GitHub repo to fix the icedove --> thunderbird name change? If so, would it be preferred to simply rename the file, or should I make a copy of it (in case some users are still using Icedove for some reason)?

Rename please.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]