New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enigmail 1.9 is incompatible with Split GPG on Debian 8 #2170

Open
andrewdavidwong opened this Issue Jul 13, 2016 · 7 comments

Comments

Projects
None yet
4 participants
@andrewdavidwong
Member

andrewdavidwong commented Jul 13, 2016

Qubes OS version (e.g., R3.1):

R3.2-rc1

Affected TemplateVMs (e.g., fedora-23, if applicable):

debian-8


Problem Description:

On 2016-07-13 08:58, 431mo6+f16909zsxw9ow via qubes-users wrote:

The signatures check does work but not the message encryption or signature.
I'm using Qubes 3.2Rc1 and using Debian 8 as the template and I have all the dom0 and template updates up to date.
Apparently it seems that the gnome-keyring is hijacking the gpg agent:

gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not interfere with the GnuPG system!
[GNUPG:] ERROR check_hijacking 33554509
[DEBUG] errorHandling.jsm: parseErrorOutputWith: return with c.errorMsg = gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not interfere with the GnuPG system!
[DEBUG] execution.jsm: EnigmailExecution.fixExitCode: agentType: gpg exitCode: 0 statusFlags 4194304
[DEBUG] encryption.jsm: encryptMessageEnd: command execution exit code: 1
[ERROR] mimeEncrypt.js: caught exception: undefined
Message: 'undefined'
File:    undefined
Line:    undefined
Stack:   undefined

Apparently there are more users complaining about the same problem issue:

https://groups.google.com/forum/?nomobile=true#!msg/qubes-users/DQUzJ39H9Cc/Arm1sU3gBQAJ

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@dmoerner

This comment has been minimized.

Show comment
Hide comment
@dmoerner

dmoerner Nov 19, 2016

Some more information, unfortunately unable to provide a fix for a Debian 8 VM:

A) Initial Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623539

B) Fixed in Debian Stretch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760102

I can confirm that this fixes the problem in a Debian 9 VM.

But how do we fix it in Debian 8? According to this blog post, https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/, you can use $GPG_AGENT_INFO to verify if gnome-keyring is hijacking gpg-agent. There seem to be three ways that people stop gnome-keyring from doing this:

  1. Add Hidden=true to /etc/xdg/autostart/gnome-keyring-gpg.desktop (https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/)
  2. Edit /etc/xdg/autostart/gnome-keyring-gpg.desktop to say "OnlyShowIn=" (http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html)
  3. Use dpkg-divert to remove /etc/xdg/autostart/gnome-keyring-gpg.desktop entirely (https://wiki.gnupg.org/GnomeKeyring)

For me, none of these options, run in the Debian-8 TemplateVM, fixes the problem. GPG_AGENT_INFO still points at gnome-keyring, and signing still fails in enigmail.

dmoerner commented Nov 19, 2016

Some more information, unfortunately unable to provide a fix for a Debian 8 VM:

A) Initial Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623539

B) Fixed in Debian Stretch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760102

I can confirm that this fixes the problem in a Debian 9 VM.

But how do we fix it in Debian 8? According to this blog post, https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/, you can use $GPG_AGENT_INFO to verify if gnome-keyring is hijacking gpg-agent. There seem to be three ways that people stop gnome-keyring from doing this:

  1. Add Hidden=true to /etc/xdg/autostart/gnome-keyring-gpg.desktop (https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/)
  2. Edit /etc/xdg/autostart/gnome-keyring-gpg.desktop to say "OnlyShowIn=" (http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html)
  3. Use dpkg-divert to remove /etc/xdg/autostart/gnome-keyring-gpg.desktop entirely (https://wiki.gnupg.org/GnomeKeyring)

For me, none of these options, run in the Debian-8 TemplateVM, fixes the problem. GPG_AGENT_INFO still points at gnome-keyring, and signing still fails in enigmail.

@dmoerner

This comment has been minimized.

Show comment
Hide comment
@dmoerner

dmoerner Nov 19, 2016

I believe the final solution to the problem can be found here: https://forums.linuxmint.com/viewtopic.php?p=1137967&sid=aa7cf2ed04063d6fe12c2dc16b1ccec7#p1137967

The first step of the solution can be implemented in any of the ways described in the previous message - change /etc/xdg/autostart/gnome-keyring-gpg.desktop such that it no longer provides the gpg-agent.

The second step is to unset GPG_AGENT_INFO before running the relevant instance of gpg2. Even when gnome-keyring isn't called with --components=gpg, it still seems to start and open a handler socket. When gpg detects that that socket is already available, it issues the warning which causes enigmail to fail, even when gnome-keyring isn't in fact functioning as gpg-agent. Unsetting GPG_AGENT_INFO is sufficient to fix this problem. (Or to patch enigmail to have a more careful detection of gnome-keyring operation, but that seems like a much more invasive solution.)

Implementing this in Qubes is slightly tricky because I'm not familiar with the implementation of qubes-gpg-client. Merely adding "unset GPG_AGENT_INFO" to qubes-gpg-client-wrapper doesn't work because it only unsets the variable on the host VM, not the target gpg VM. Adding an implementation of "unset GPG_AGENT_INFO" to qubes-gpg-client is what is really needed.

Cc'ing @marmarek (I hope this is OK).

One way to implement this solution would be to add a dpkg-divert instance (following https://wiki.gnupg.org/GnomeKeyring) to the postinst and postrm files for the qubes-gpg-split Debian package, and then unset GPG_AGENT_INFO in qubes-gpg-client. One thing I'm not sure about is the risk of blindly unsetting GPG_AGENT_INFO. Is there a risk? At the very least it would be nice to limit it to cases where we are running Debian.

Daniel

I believe the final solution to the problem can be found here: https://forums.linuxmint.com/viewtopic.php?p=1137967&sid=aa7cf2ed04063d6fe12c2dc16b1ccec7#p1137967

The first step of the solution can be implemented in any of the ways described in the previous message - change /etc/xdg/autostart/gnome-keyring-gpg.desktop such that it no longer provides the gpg-agent.

The second step is to unset GPG_AGENT_INFO before running the relevant instance of gpg2. Even when gnome-keyring isn't called with --components=gpg, it still seems to start and open a handler socket. When gpg detects that that socket is already available, it issues the warning which causes enigmail to fail, even when gnome-keyring isn't in fact functioning as gpg-agent. Unsetting GPG_AGENT_INFO is sufficient to fix this problem. (Or to patch enigmail to have a more careful detection of gnome-keyring operation, but that seems like a much more invasive solution.)

Implementing this in Qubes is slightly tricky because I'm not familiar with the implementation of qubes-gpg-client. Merely adding "unset GPG_AGENT_INFO" to qubes-gpg-client-wrapper doesn't work because it only unsets the variable on the host VM, not the target gpg VM. Adding an implementation of "unset GPG_AGENT_INFO" to qubes-gpg-client is what is really needed.

Cc'ing @marmarek (I hope this is OK).

One way to implement this solution would be to add a dpkg-divert instance (following https://wiki.gnupg.org/GnomeKeyring) to the postinst and postrm files for the qubes-gpg-split Debian package, and then unset GPG_AGENT_INFO in qubes-gpg-client. One thing I'm not sure about is the risk of blindly unsetting GPG_AGENT_INFO. Is there a risk? At the very least it would be nice to limit it to cases where we are running Debian.

Daniel

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Nov 19, 2016

Member

If that's only about GPG_AGENT_INFO, then this is a duplicate of #2351, for which fix is already in testing repository for R3.2.

Member

marmarek commented Nov 19, 2016

If that's only about GPG_AGENT_INFO, then this is a duplicate of #2351, for which fix is already in testing repository for R3.2.

@dmoerner

This comment has been minimized.

Show comment
Hide comment
@dmoerner

dmoerner Nov 19, 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/19/2016 12:57 PM, Marek Marczykowski-Górecki wrote:

If that's only about |GPG_AGENT_INFO|, then this is a duplicate of
#2351 #2351, for
which fix is already in testing repository for R3.2.

Great! It looks like that will fix part of the problem. This bug isn't
exactly a duplicate of 2351, because there's still a further problem
with gnome-keyring providing gpg-agent by default.

However, an explanation of how to disable this as a user is already
present in /usr/share/doc/gnome-keyring/README.Debian. (Although it's
kind of a poor explanation, here's a better one:
https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/)

So once #2351 is closed and the fix is verified to work with gpg agent
(which I unfortunately can't do since I don't have hardware where I am
willing to install from the testing repo), then this can also be closed.

Thanks,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIwBAEBCAAaBQJYMJWlExxkbW9lcm5lckBnbWFpbC5jb20ACgkQyz0BTtfxsyqO
vRAAt0EWVHiSp2NkP4Eix76Os6eUflWArNhDEnGlEzWbvk6b5upv/XgHSqCm2rIS
I/WE5VWswmo1S65HTSvewiV0zHWYli+2XwU7AlJP1Op2fEtOabL25TC7u5NmU9wb
jUso2dWnfkfQmjOO8AkBWCdtj53AI/W2JgKKPIcMKuudNNwP+kbt1Fmzb7fX1BLj
jSqaY8GgEhb/hDYGxWRt9Zxxrhdrq+sunYhW8zl9VFzihAUQsvOhKzKHpV0Rp7ir
u2OlsiZY7hXVO+/Lr7VkfAzQJu8IXf7r9VNXmIdtK4kvJOrdlbb8peknXHMpgmoQ
ooe7GlzaYrh3KYWyaBr78DU2LOZcsHxQmpe8bETbwAJNmRPhrB/OucWwDJB8Gqx2
iobTok/4NDTFk1Ihi2wQAuJPr4Erzi1IxmONn8BlMuHXhy4EQm9qeKyoA6Ts4c9t
eeFPsf1jvo6ZuAyqsrsAFriWlRfpbsk9EjgQnRPCW9Xp46GVHZmzHe919zxCDBHe
G5gE0o458zGJEl10V9fj4XKbDNRkmlRrEnv4fNeUqdQMpWWYe6s781IkiVMLdF6B
dzUoISQiKGTiznA2RGFL4anOspld194zcUwlJhRLwng5/yMB8QAno/Mk+sBvGKyX
kheZxMnxFlak5290UhIevzNWEJpwzWzMiicAEjCYJKuo7OA=
=1Pns
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/19/2016 12:57 PM, Marek Marczykowski-Górecki wrote:

If that's only about |GPG_AGENT_INFO|, then this is a duplicate of
#2351 #2351, for
which fix is already in testing repository for R3.2.

Great! It looks like that will fix part of the problem. This bug isn't
exactly a duplicate of 2351, because there's still a further problem
with gnome-keyring providing gpg-agent by default.

However, an explanation of how to disable this as a user is already
present in /usr/share/doc/gnome-keyring/README.Debian. (Although it's
kind of a poor explanation, here's a better one:
https://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/)

So once #2351 is closed and the fix is verified to work with gpg agent
(which I unfortunately can't do since I don't have hardware where I am
willing to install from the testing repo), then this can also be closed.

Thanks,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIwBAEBCAAaBQJYMJWlExxkbW9lcm5lckBnbWFpbC5jb20ACgkQyz0BTtfxsyqO
vRAAt0EWVHiSp2NkP4Eix76Os6eUflWArNhDEnGlEzWbvk6b5upv/XgHSqCm2rIS
I/WE5VWswmo1S65HTSvewiV0zHWYli+2XwU7AlJP1Op2fEtOabL25TC7u5NmU9wb
jUso2dWnfkfQmjOO8AkBWCdtj53AI/W2JgKKPIcMKuudNNwP+kbt1Fmzb7fX1BLj
jSqaY8GgEhb/hDYGxWRt9Zxxrhdrq+sunYhW8zl9VFzihAUQsvOhKzKHpV0Rp7ir
u2OlsiZY7hXVO+/Lr7VkfAzQJu8IXf7r9VNXmIdtK4kvJOrdlbb8peknXHMpgmoQ
ooe7GlzaYrh3KYWyaBr78DU2LOZcsHxQmpe8bETbwAJNmRPhrB/OucWwDJB8Gqx2
iobTok/4NDTFk1Ihi2wQAuJPr4Erzi1IxmONn8BlMuHXhy4EQm9qeKyoA6Ts4c9t
eeFPsf1jvo6ZuAyqsrsAFriWlRfpbsk9EjgQnRPCW9Xp46GVHZmzHe919zxCDBHe
G5gE0o458zGJEl10V9fj4XKbDNRkmlRrEnv4fNeUqdQMpWWYe6s781IkiVMLdF6B
dzUoISQiKGTiznA2RGFL4anOspld194zcUwlJhRLwng5/yMB8QAno/Mk+sBvGKyX
kheZxMnxFlak5290UhIevzNWEJpwzWzMiicAEjCYJKuo7OA=
=1Pns
-----END PGP SIGNATURE-----

@entr0py

This comment has been minimized.

Show comment
Hide comment
@entr0py

entr0py Nov 19, 2016

Sorry to chime in on this late - AFTER @dmoerner did all his research.

The reported bug shouldn't really be a relevant issue since Enigmail 1.9 is not contained in Debian-8 repos to begin with. (https://packages.debian.org/en/jessie/enigmail) I imagine the OP got 1.9 into Jessie by either running a mixed-Stretch distro or downloading directly from enigmail.net. (I do not see any way to update Enigmail from within Icedove.) In any case, Qubes support shouldn't have to extend beyond what Debian's package maintainers are tracking. Enigmail 1.8 works fine in Jessie and Daniel confirms that 1.9 works with Stretch.

entr0py commented Nov 19, 2016

Sorry to chime in on this late - AFTER @dmoerner did all his research.

The reported bug shouldn't really be a relevant issue since Enigmail 1.9 is not contained in Debian-8 repos to begin with. (https://packages.debian.org/en/jessie/enigmail) I imagine the OP got 1.9 into Jessie by either running a mixed-Stretch distro or downloading directly from enigmail.net. (I do not see any way to update Enigmail from within Icedove.) In any case, Qubes support shouldn't have to extend beyond what Debian's package maintainers are tracking. Enigmail 1.8 works fine in Jessie and Daniel confirms that 1.9 works with Stretch.

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Nov 22, 2016

Member

Enigmail 1.9 is available from addons.mozilla.org, and Qubes is willing to support the latest version available from that source, so I'm reopening this issue.

Member

andrewdavidwong commented Nov 22, 2016

Enigmail 1.9 is available from addons.mozilla.org, and Qubes is willing to support the latest version available from that source, so I'm reopening this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment