Hello, I've been receiving an error (below) since I've updated gnupg to version 2.0.x which I was forced to do this morning. This error occurs during creation of the revocation certificate (but it still lets me save the certificate), when trying to send an encrypted and/or signed message, and when attempting to revoke a key.
Doesn't help. I have the same trouble (Lubuntu). I already had GnuPG 2.x before, so the problem must arise from the new Enigmail version 1.9, since it started precisely with the installation of the new Enigmail version.
At least, decryption works after 3 clicks on "OK"; however, the icons (signature, encryption) and the Enigmail info text are missing (so I think I know why there are 3 error messages).
Enigmail 1.9 on MacOS works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got the same problem with debian jessie. gnupg is 2.x, gpg-agent is installed. running into this problems with update to 1.9.
seems to be related to this:
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 33532147 [GNUPG:] GOOD_PASSPHRASE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But: after disabling the GPG-agent-part of the Gnome keyring I have to
enter the password twice before the mail is signed/encrypted. I still
have no idea how to fix that.
So how to fix this. The idea of gnome-keyring is to have the passphrase unlocked when logging in. I do not want to enter passphrases all the time / when using thunderbird or the like. Any idea about that? What about a switch to disable the hijacking checking? Or an option to suppress the notification?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Similar here: Using LMDE2 Mate (Linux Mint Debian Ed. 2 Betsy, Jessie based) on several machines, some upgraded from LMDE1, some x64, some x32. They use by default gnome-keyring (GKR); the upgraded ones complicate it further because previously they used mate-keyring now dropped from the Mate project. gpg version 1.4.18 and gpg2 ver. 2.0.26 are installed.
Since today (since Enigmail V1.9) after entering the Enigmail passprase it complains about a communication error between GnuPG and gpg-agent. After clicking OK it does decrypt my inbox mails but I cannot send encrypted mails.
(On another machine since quite some time one has to enter the passphrase twice, every time, for every mail and every attachment.)
I then did the following:
• apt purge mate-keyring
• As advised in the link two above, I copied gnome-keyring-gpg.desktop from /etc/xdg/autostart to ~/.config/autostart/
• In Mate's Settings | Start Programs I unchecked the entry with /usr/bin/gnome-keyring-daemon --start --components=gpg (which added X-MATE-Autostart-enabled=false to the above .desktop file). Three other /usr/bin/gnome-keyring-daemon entries with --start --components=secrets and --start --components=ssh and --start --components=pkcs11 remain active.
• In Mate's Settings | Start Programs I manually added an entry with /usr/bin/gpg-agent --daemon .
• Logged out and back in: No improvement! Although ps -e does list /usr/bin/gpg-agent --daemon running.
• In TB, Enigmail's settings for the passphrase still complain about a specialized tool like gnome-keyring.
• $GPG_AGENT_INFO is /run/user/1000/keyring/gpg:0:1 and gpg still complains about GKR's hijacking.
• Deleted ~/.config/autostart/gnome-keyring-gpg.desktop again.
• sudo dpkg-divert --local --rename --divert /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable --add /etc/xdg/autostart/gnome-keyring-gpg.desktop
• Logged out/in, even rebooted — still the same! WTF? I'm obviously missing something, but what?? This effectively now blocks our mail encryption.
Try what I might, I cannot stop GKR from hijacking!
In terminal, I can manually set GPG_AGENT_INFO to the momentary randomized gpg-agent's socket, then gpg works on the command line, but on every login it is set again to GKR's socket.
I tried several methods from above, I completely deleted gnome-keyring-gpg.desktop from /etc/xdg/autostart and ~/.config/autostart/ — no change.
How can I stop GKR doing that?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@patrick: thanks that works but it also means that i would have to enter the passphrase at least once after reboot.
Would it be possible to make enigmail like it used to be regarding this problem? In other words : would you mind to consider keeping the functionality like it was up to 1.8?
Maybe via an 'ignore' option or so. Whatever would be best (exept entering passphrases ;)
This would be very appreciated.
Thanks for considering!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On another upgraded LMDE2/Mate system I still have the (deprecated) mate-keyring-daemon running (not GKR) with the secrets, ssh and pkcs11 components, and gpg-agent --daemon --enable-ssh-support --use-standard-socket — there Enigmail and commandline gpg seem to work and GPG_AGENT_INFO is not set.
Who sets GPG_AGENT_INFO and how can I prevent that?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
manuca, the Enigmail internal passphrase handling only worked for GnuPG 1.4.x and had a lot of disadvantages. Having something similar for GnuPG 2.x would require Enigmail to add just another thing like gpg-agent or gnome-keyring. There are already too many tools like this as you can see.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You cannot replace gpg-agent with something else. In GnuPG 2.0.x gpg-agent would only do passphrase handling (which theoretically could be done with another tool). But in GnuPG 2.1, gpg-agent also does key management and crypto operations, and is therefore not replaceable in any way. The only way to go forward in the long term is to use the original gpg-agent.
It's not a decision taken by Enigmail that gpg-agent is mandatory and works the way it does - that a decision taken by GnuPG developers, and we cannot change or influence it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not a decision taken by Enigmail that gpg-agent is mandatory and works the way it does - that a decision taken by GnuPG developers, and we cannot change or influence it.
@Patrik Brunschwig: I see. Fair enough that you cannot change or influence it.
But I still wonder what has changed in enigmail from 1.8 to 1.9 regarding the gnupg-agent. Meaning why is it not possible to keep the old behavoir with the passphrases?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There have been two changes between v1.8 and v1.9:
* I removed support for GnuPG 1.4
* With view to GnuPG 2.1 (which was released after Enigmail 1.8) I started to intepret some of the error messages of GnuPG and react to them. One of the messages I check is "ERROR check_hijacking", because this message will break GnuPG 2.1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
then making sure that no other such entries are in ~/.config/autostart and rebooting does not help: gnome-keyring still sets up all four sockets in /var/run /user/<uid>/keyring and $GPG_AGENT_INFO.
I see this as a serious bug in Mate's gnome-keyring. </uid>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Patrik Brunschwig: This gnome-keyring ist getting seriously annoying!
Wouldn't it be possible for Enigmail to ignore $GPG_AGENT_INFO and to use ~/.gpg-agent-info (if existing) instead? Assuming one starts
This way I have gpg-agent running and know its socket and can use it although gnome-keyring afterwards sets GPG_AGENT_INFO as far as I can see?
While I don't see a way to reset GPG_AGENT_INFO to gpg-agent's socket for my whole Mate session.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, Enigmail cannot do this, and no, this is not the usual way to start gpg-agent. Usually GPG_AGENT_INFO is correctly set and is useful. The solution needs to be on your side, it cannot be in Enigmail.
I believe that gnome-keyring is started in your profile (e.g. .xinitrc, .sessionrc or similar). You might just as well write a wrapper to start Thunderbird which would unset GPG_AGENT_INFO:
Patrick, of course gnome-keyring is started with my session, namely via /etc/xdg/autostart desktop entries, as written above. And like most people I need a keyring, for instance for network-manager. The problem is that (only in LMDE's Mate?) it stubbornly insists on hijacking gpg although only its secrets and pkcs11 components are started. (I looked in all places.) My gpg-agent does not set GPG_AGENT_INFO at all! (Is that why use-standard-socket is often needed?) mate-keyring is better behaved, it does not set up a gpg socket or GPG_AGENT_INFO if not called for.
Your wrapper script from above is a good and simple idea, though only for TB. I'll try it. Instead unsetting I could also source ~/.gpg-agent-info . But I don't see why Enigmail couldn't also check for ~/.gpg-agent-info — it looks safer to me since it is only generated by gpg-agent but not by gnome-keyring.
My workaround for now was to downgrade from the botched gnome-keyring to the less intrusive mate-keyring. Since it is deprecated and no longer in the repos, I had to fetch the deb packages:
I already had set up via Mate's Settings | Start Programs an autostart “GPG Agent” with /usr/bin/gpg-agent --daemon
(creates ~/.config/autostart/gpg-agent.desktop) and a ~/.gnupg/gpg-agent.conf with
Now my Thunderbird with Enigmail 1.9 runs smoothly again. I just lost a day of my life…
The divert and gpg-agent autostart is probably not necessary here since I think that mate-keyring just starts gpg-agent for its gpg component instead of doing/botching its own thing. With gnome-keyring it is necessary but not even sufficient because… see above.
The ttl entries are for caching the passphrase for a work day; the pinentry usually should not be necessary; the use-standard-socket seems necessary for Enigmail (because gpg-agent does not set GPG_AGENT_INFO?); the write-env-file is hopefully for a future better workaround by Enigmail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I've been receiving an error (below) since I've updated gnupg to version 2.0.x which I was forced to do this morning. This error occurs during creation of the revocation certificate (but it still lets me save the certificate), when trying to send an encrypted and/or signed message, and when attempting to revoke a key.
Last edit: ultimoblaze 2016-02-25
Please open the link that the error message displays. It points you to a troubleshooting guide for resolving this issue.
Doesn't help. I have the same trouble (Lubuntu). I already had GnuPG 2.x before, so the problem must arise from the new Enigmail version 1.9, since it started precisely with the installation of the new Enigmail version.
At least, decryption works after 3 clicks on "OK"; however, the icons (signature, encryption) and the Enigmail info text are missing (so I think I know why there are 3 error messages).
Enigmail 1.9 on MacOS works fine.
If you attach a debug log file, I'll tell you what's wrong and why Enigmail complains.
Got the same problem with debian jessie. gnupg is 2.x, gpg-agent is installed. running into this problems with update to 1.9.
seems to be related to this:
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 33532147
[GNUPG:] GOOD_PASSPHRASE
This is something I really recommend to fix, otherwise GnuPG will not work correctly in the long term. The following post describes how to fix it:
https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2016-February/003674.html
Thanks for pointing to this post.
But the poster writes:
So how to fix this. The idea of gnome-keyring is to have the passphrase unlocked when logging in. I do not want to enter passphrases all the time / when using thunderbird or the like. Any idea about that? What about a switch to disable the hijacking checking? Or an option to suppress the notification?
Similar here: Using LMDE2 Mate (Linux Mint Debian Ed. 2 Betsy, Jessie based) on several machines, some upgraded from LMDE1, some x64, some x32. They use by default gnome-keyring (GKR); the upgraded ones complicate it further because previously they used mate-keyring now dropped from the Mate project. gpg version 1.4.18 and gpg2 ver. 2.0.26 are installed.
Since today (since Enigmail V1.9) after entering the Enigmail passprase it complains about a communication error between GnuPG and gpg-agent. After clicking OK it does decrypt my inbox mails but I cannot send encrypted mails.
(On another machine since quite some time one has to enter the passphrase twice, every time, for every mail and every attachment.)
I then did the following:
• apt purge mate-keyring
• As advised in the link two above, I copied gnome-keyring-gpg.desktop from /etc/xdg/autostart to ~/.config/autostart/
• In Mate's Settings | Start Programs I unchecked the entry with /usr/bin/gnome-keyring-daemon --start --components=gpg (which added X-MATE-Autostart-enabled=false to the above .desktop file). Three other /usr/bin/gnome-keyring-daemon entries with --start --components=secrets and --start --components=ssh and --start --components=pkcs11 remain active.
• In Mate's Settings | Start Programs I manually added an entry with /usr/bin/gpg-agent --daemon .
• Logged out and back in: No improvement! Although ps -e does list /usr/bin/gpg-agent --daemon running.
• In TB, Enigmail's settings for the passphrase still complain about a specialized tool like gnome-keyring.
• $GPG_AGENT_INFO is /run/user/1000/keyring/gpg:0:1 and gpg still complains about GKR's hijacking.
• Deleted ~/.config/autostart/gnome-keyring-gpg.desktop again.
• sudo dpkg-divert --local --rename --divert /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable --add /etc/xdg/autostart/gnome-keyring-gpg.desktop
• Logged out/in, even rebooted — still the same! WTF? I'm obviously missing something, but what?? This effectively now blocks our mail encryption.
From auth.log see attached auth.txt
Hans: GPG_AGENT_INFO points to a wrong location. It's best to make sure the environment variable is not set.
How?
manuca: try changing the timeout setting in the Enigmail preferences to a large value (e.g. 9999 minutes).
Try what I might, I cannot stop GKR from hijacking!
In terminal, I can manually set GPG_AGENT_INFO to the momentary randomized gpg-agent's socket, then gpg works on the command line, but on every login it is set again to GKR's socket.
I tried several methods from above, I completely deleted gnome-keyring-gpg.desktop from /etc/xdg/autostart and ~/.config/autostart/ — no change.
How can I stop GKR doing that?
@patrick: thanks that works but it also means that i would have to enter the passphrase at least once after reboot.
Would it be possible to make enigmail like it used to be regarding this problem? In other words : would you mind to consider keeping the functionality like it was up to 1.8?
Maybe via an 'ignore' option or so. Whatever would be best (exept entering passphrases ;)
This would be very appreciated.
Thanks for considering!
On another upgraded LMDE2/Mate system I still have the (deprecated) mate-keyring-daemon running (not GKR) with the secrets, ssh and pkcs11 components, and gpg-agent --daemon --enable-ssh-support --use-standard-socket — there Enigmail and commandline gpg seem to work and GPG_AGENT_INFO is not set.
Who sets GPG_AGENT_INFO and how can I prevent that?
Hans , have you checked the usual suspects like ~/.profile, ~/.bashrc, ~/.xsessionrc or ~/.xinitrc ?
Nothing there… On both machines grep only finds a /etc/X11/Xsession.d/90gpg-agent which checks for $GPG_AGENT_INFO or gpg-agent already running.
To me, it looks like GKR starts all its components, sets up all its four sockets and GPG_AGENT_INFO even though the gpg component is not called for…?
I've left now the first machine for the weekend, will return to it on Monday,
manuca, the Enigmail internal passphrase handling only worked for GnuPG 1.4.x and had a lot of disadvantages. Having something similar for GnuPG 2.x would require Enigmail to add just another thing like gpg-agent or gnome-keyring. There are already too many tools like this as you can see.
You cannot replace gpg-agent with something else. In GnuPG 2.0.x gpg-agent would only do passphrase handling (which theoretically could be done with another tool). But in GnuPG 2.1, gpg-agent also does key management and crypto operations, and is therefore not replaceable in any way. The only way to go forward in the long term is to use the original gpg-agent.
It's not a decision taken by Enigmail that gpg-agent is mandatory and works the way it does - that a decision taken by GnuPG developers, and we cannot change or influence it.
@Patrik Brunschwig: I see. Fair enough that you cannot change or influence it.
But I still wonder what has changed in enigmail from 1.8 to 1.9 regarding the gnupg-agent. Meaning why is it not possible to keep the old behavoir with the passphrases?
There have been two changes between v1.8 and v1.9:
* I removed support for GnuPG 1.4
* With view to GnuPG 2.1 (which was released after Enigmail 1.8) I started to intepret some of the error messages of GnuPG and react to them. One of the messages I check is "ERROR check_hijacking", because this message will break GnuPG 2.1
Here's how I disabled Gnome Keyring and enabled gpg-agent on Mint 17.3 Cinnamon (which is based on Ubuntu 14.04):
(default install)
(install gnupg2)
mv /etc/xdg/autostart/gnome-keyring-gpg.desktop /etc/xdg/autostart/gnome-keyring-gpg.desktop.disabled
echo "use-agent" >>~/.gnupg/gpg.conf
(import your keys)
(reboot)
Note that you need a new session, thus either log out and back in or simply reboot.
Last edit: Olav Seyfarth 2016-03-03
No luck here in LMDE2 with Mate 1.12.01+betsy… disabling both gpg and ssh via
then making sure that no other such entries are in ~/.config/autostart and rebooting does not help: gnome-keyring still sets up all four sockets in /var/run /user/<uid>/keyring and $GPG_AGENT_INFO.
I see this as a serious bug in Mate's gnome-keyring. </uid>
@Patrik Brunschwig: This gnome-keyring ist getting seriously annoying!
Wouldn't it be possible for Enigmail to ignore $GPG_AGENT_INFO and to use ~/.gpg-agent-info (if existing) instead? Assuming one starts
This way I have gpg-agent running and know its socket and can use it although gnome-keyring afterwards sets GPG_AGENT_INFO as far as I can see?
While I don't see a way to reset GPG_AGENT_INFO to gpg-agent's socket for my whole Mate session.
No, Enigmail cannot do this, and no, this is not the usual way to start gpg-agent. Usually GPG_AGENT_INFO is correctly set and is useful. The solution needs to be on your side, it cannot be in Enigmail.
I believe that gnome-keyring is started in your profile (e.g. .xinitrc, .sessionrc or similar). You might just as well write a wrapper to start Thunderbird which would unset GPG_AGENT_INFO:
Patrick, of course gnome-keyring is started with my session, namely via /etc/xdg/autostart desktop entries, as written above. And like most people I need a keyring, for instance for network-manager. The problem is that (only in LMDE's Mate?) it stubbornly insists on hijacking gpg although only its secrets and pkcs11 components are started. (I looked in all places.) My gpg-agent does not set GPG_AGENT_INFO at all! (Is that why use-standard-socket is often needed?) mate-keyring is better behaved, it does not set up a gpg socket or GPG_AGENT_INFO if not called for.
Your wrapper script from above is a good and simple idea, though only for TB. I'll try it. Instead unsetting I could also source ~/.gpg-agent-info . But I don't see why Enigmail couldn't also check for ~/.gpg-agent-info — it looks safer to me since it is only generated by gpg-agent but not by gnome-keyring.
My workaround for now was to downgrade from the botched gnome-keyring to the less intrusive mate-keyring. Since it is deprecated and no longer in the repos, I had to fetch the deb packages:
I already had set up via Mate's Settings | Start Programs an autostart “GPG Agent” with
/usr/bin/gpg-agent --daemon(creates ~/.config/autostart/gpg-agent.desktop) and a ~/.gnupg/gpg-agent.conf with
Now my Thunderbird with Enigmail 1.9 runs smoothly again. I just lost a day of my life…
The divert and gpg-agent autostart is probably not necessary here since I think that mate-keyring just starts gpg-agent for its gpg component instead of doing/botching its own thing. With gnome-keyring it is necessary but not even sufficient because… see above.
The ttl entries are for caching the passphrase for a work day; the pinentry usually should not be necessary; the use-standard-socket seems necessary for Enigmail (because gpg-agent does not set GPG_AGENT_INFO?); the write-env-file is hopefully for a future better workaround by Enigmail.