[arch-general] mutt and gnupg
It seems a recent upgrade of gnupg (I'm at 2.1.0-6) has degraded my mutt config slightly. I've just compared my gpg-related config of mutt to /usr/share/doc/mutt/samples/gpg.rc and they match. Beyond what's found there I also have the following settings: set crypt_autoencrypt = no set crypt_autosign = yes set crypt_autosmime = no set crypt_replyencrypt = yes set crypt_replysign = yes set crypt_replysignencrypted = yes set crypt_use_gpgme = no set pgp_sign_as = 0xAB4DFBA4 set pgp_use_gpg_agent = yes set smime_is_default = no The behaviour that changed after the recent upgrade of gnupg was that mutt started asking me for a password. Before the upgrade it didn't, it handed over to the gpg-agent right away. My testing suggests that the value of `pgp_use_gpg_agent` has no influence on mutt's behaviour at all any more. However, if I do set `crypt_use_gpgme` mutt hands off to the gpg-agent right away. However, if I set that mutt reports the following when started: Using GPGME backend, although no gpg-agent is running So, is there some way to configure mutt to go straight to the gpg-agent, without any warning messages on startup? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler
On Fri, Dec 5, 2014 at 3:53 AM, Magnus Therning <magnus@therning.org> wrote:
So, is there some way to configure mutt to go straight to the gpg-agent, without any warning messages on startup?
I fought with this as soon as it came out and engaged upstream - v2.1.x requires the agent and pinentry, you'll need to work out a change in your configuration to use "loopback" mode in pinentry. Based on the forum thread and upstream bug report I worked out these instructions for a general case: https://wiki.archlinux.org/index.php/Gnupg#Unattended_passphrase If you figure out another case that is needed, please update the wiki with your new find. :) -te
On Fri, Dec 05, 2014 at 09:55:22AM -0600, Troy Engel wrote:
On Fri, Dec 5, 2014 at 3:53 AM, Magnus Therning <magnus@therning.org> wrote:
So, is there some way to configure mutt to go straight to the gpg-agent, without any warning messages on startup?
I fought with this as soon as it came out and engaged upstream - v2.1.x requires the agent and pinentry, you'll need to work out a change in your configuration to use "loopback" mode in pinentry. Based on the forum thread and upstream bug report I worked out these instructions for a general case:
https://wiki.archlinux.org/index.php/Gnupg#Unattended_passphrase
If you figure out another case that is needed, please update the wiki with your new find. :)
Hmm, that configuration basically makes GnuPG *not* use the pinentry program and makes mutt completely bypass the use of gpg-agent. I rather like gpg-agent and the pinentry program... so I'd much rather configure mutt to work with standard behaviour of v2.1.x. Is that possible? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
On 06/12/14 at 10:36pm, Magnus Therning wrote:
On Fri, Dec 05, 2014 at 09:55:22AM -0600, Troy Engel wrote:
On Fri, Dec 5, 2014 at 3:53 AM, Magnus Therning <magnus@therning.org> wrote:
So, is there some way to configure mutt to go straight to the gpg-agent, without any warning messages on startup?
I fought with this as soon as it came out and engaged upstream - v2.1.x requires the agent and pinentry, you'll need to work out a change in your configuration to use "loopback" mode in pinentry. Based on the forum thread and upstream bug report I worked out these instructions for a general case:
https://wiki.archlinux.org/index.php/Gnupg#Unattended_passphrase
If you figure out another case that is needed, please update the wiki with your new find. :)
Hmm, that configuration basically makes GnuPG *not* use the pinentry program and makes mutt completely bypass the use of gpg-agent.
I rather like gpg-agent and the pinentry program... so I'd much rather configure mutt to work with standard behaviour of v2.1.x. Is that possible?
Yes, but you do need to move to GPGME (or at least that was the only way I restored that functionality). Update your gpg configuration in your mutt files: set crypt_use_gpgme = yes Then in your shell profile file, set a couple of variables: export GPG_TTY=$(tty) export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent Now you will get the pinentry prompt in mutt, and your gpg-agent will continue to work for other services (which the loopback hack breaks, as noted in the GPG release notes). /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40]
On Sun, Dec 07, 2014 at 10:45:45AM +1300, Jason Ryan wrote:
On 06/12/14 at 10:36pm, Magnus Therning wrote:
On Fri, Dec 05, 2014 at 09:55:22AM -0600, Troy Engel wrote:
On Fri, Dec 5, 2014 at 3:53 AM, Magnus Therning <magnus@therning.org> wrote:
So, is there some way to configure mutt to go straight to the gpg-agent, without any warning messages on startup?
I fought with this as soon as it came out and engaged upstream - v2.1.x requires the agent and pinentry, you'll need to work out a change in your configuration to use "loopback" mode in pinentry. Based on the forum thread and upstream bug report I worked out these instructions for a general case:
https://wiki.archlinux.org/index.php/Gnupg#Unattended_passphrase
If you figure out another case that is needed, please update the wiki with your new find. :)
Hmm, that configuration basically makes GnuPG *not* use the pinentry program and makes mutt completely bypass the use of gpg-agent.
I rather like gpg-agent and the pinentry program... so I'd much rather configure mutt to work with standard behaviour of v2.1.x. Is that possible?
Yes, but you do need to move to GPGME (or at least that was the only way I restored that functionality).
Update your gpg configuration in your mutt files: set crypt_use_gpgme = yes
Then in your shell profile file, set a couple of variables: export GPG_TTY=$(tty) export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent
Now you will get the pinentry prompt in mutt, and your gpg-agent will continue to work for other services (which the loopback hack breaks, as noted in the GPG release notes).
IIRC those used to *have* to be set, and that was done via the loginmanager (e.g. gdm), but that doesn't seem to be necessary any longer, but I guess mutt depends on them being there in order to find out that gpg-agent is running. Is that correct? Anyway, making the changes you propose makes mutt behave the way I want. Thanks! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous
On Sun, Dec 07, 2014 at 10:45:45AM +1300, Jason Ryan wrote:
Yes, but you do need to move to GPGME (or at least that was the only way I restored that functionality).
Why? Where is it written?
Update your gpg configuration in your mutt files: set crypt_use_gpgme = yes
This variable can certainly be set. However, by itself it doesn't do anything to help mutt discover the running gpg-agent.
Then in your shell profile file, set a couple of variables: export GPG_TTY=$(tty) export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent
This is also unnecessary. The first variable should anyway be set in the .bashrc (or similar). The 2nd one is not needed to be exported globally. The real solution would be for mutt to look for gpg-agent sockets. Currently, mutt just seems to check GPG_AGENT_INFO in env and ask for a passwd if it is not set. It follows that the simplest workaround is to change mutt invocation as ------ $ env | grep GPG GPG_TTY=/dev/pts/4 $ GPG_AGENT_INFO="" mutt ------ and leave muttrc alone. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 22/12/14 at 02:27pm, Leonid Isaev wrote:
On Sun, Dec 07, 2014 at 10:45:45AM +1300, Jason Ryan wrote:
Yes, but you do need to move to GPGME (or at least that was the only way I restored that functionality).
Why? Where is it written?
(or at least that was the only way I restored that functionality)
Update your gpg configuration in your mutt files: set crypt_use_gpgme = yes
This variable can certainly be set. However, by itself it doesn't do anything to help mutt discover the running gpg-agent.
Then in your shell profile file, set a couple of variables: export GPG_TTY=$(tty) export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent
This is also unnecessary. The first variable should anyway be set in the .bashrc (or similar). The 2nd one is not needed to be exported globally.
The real solution would be for mutt to look for gpg-agent sockets. Currently, mutt just seems to check GPG_AGENT_INFO in env and ask for a passwd if it is not set.
It follows that the simplest workaround is to change mutt invocation as ------ $ env | grep GPG GPG_TTY=/dev/pts/4 $ GPG_AGENT_INFO="" mutt ------
and leave muttrc alone.
So, we only disagree about the content of the variable; ie., it *has* to exist, but it doesn't matter what is in it, or even if it is empty… /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40]
On Tue, Dec 23, 2014 at 10:44:35AM +1300, Jason Ryan wrote:
So, we only disagree about the content of the variable; ie., it *has* to exist, but it doesn't matter what is in it, or even if it is empty…
Yes. However, I don't see why you need to export it globally and I also don't understand why using the GPGME backend should help. By looking at mutt src, it seems that GPGME backend (crypt-gpgme.c) uses the same logic regarding the gpg-agent as the classic PGP backend (pgp.c). Namely, both invoke !getenv("GPG_AGENT_INFO") to check if a gpg-agent is running. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (4)
-
Jason Ryan
-
Leonid Isaev
-
Magnus Therning
-
Troy Engel