pinentry-curses fails after max-cache-ttl expires

jasonwryan · 2016-11-10 21:24:15

On my work machine, I set a long max-cache-ttl so that my keys are stored while I am working.

Of late (probably a couple of days, but pacman log shows no obviously related updates) pinentry-curses will not show up after the cache expires, so mutt just hangs waiting for the signature and eventually times out with the message:

error signing data: Operation cancelled?

My .gnupg/gpg-agent.conf specifies pinentry-curses, if I change this to anything else (pinentry, or pinentry-gtk), the GTK prompt appears immediately, so it is definitely an issue with the curses program and the term in mutt.

If I run a shell command in mutt: echo $GPG_AGENT_INFO it returns the correct value: /home/jason/.gnupg/S.gpg-agent

In my .profile I export the correct variables:

export GPG_TTY=$(tty)
export GPG_AGENT_INFO=$HOME/.gnupg/S.gpg-agent

I have made no other changes to my environment, I don't force a term variable, but still pinentry-curses seems to lose the ability to "find" the term mutt is running in.

I can "fix" it by killing the running agent and using another program to summon the pinentry in a different term (like `pass -c secretkey`): switching terms to mutt and resending the mail will immediately bring up the curses pinentry.

Does anyone else have a similar setup and experiences this issue?

# edit: so, running mutt in xterm works (xterm-256color) but fails in urxvt (rxvt-unicode-256color). pinentry-curses works in termite (xterm-termite) as well; seems this is a terminfo issue. Theory disproven.

jasonwryan · 2016-11-11 00:20:13

Narrowed it down further.

I normally start mutt from a keybind in dwm:

mailcmd[] = { "urxvtc", "-title", "mutt", "-e", "mutt", NULL };

where pinentry-curses fails after the cache expires.

If I start the terminal from a keybind:

termcmd[] = { "urxvtc", NULL };

and then start mutt manually, pinentry-curses comes up straight away after the cache has expired.

So it isn't terminfo related, but is tied to the way mutt is started within the term...

Trilby · 2016-11-11 00:43:07

I'd try the following two bindings to gather more data points:

mailcmd[] = { "urxvtc", "-e", "bash -c mutt", NULL };
mailcmd[] = { "urxvtc", "-ls", "-e", "mutt", NULL };

jasonwryan · 2016-11-11 01:10:16

Thanks Trilby. Starting as a login shell exhibits the same failure. Starting from bash fails to open a window at all.

Trilby · 2016-11-11 01:32:24

Odd that bash fails to run at all, but those were essentially redundant tests, so it's not a login-shell issue.

jasonwryan · 2016-11-16 21:54:24

Now that the earthquake is out of the way, I can refocus on this...

So it is definitely the difference between starting from a dwm keybind and just executing mutt in the terminal. I ran `printenv` in both when pinentry was working and when it failed and the only difference was the windowid. So, it isn't something in the environment that changes, which leaves me wondering what else it could be.

I can happliy work around this, but I am curious about what has changed (this worked fine for years) and what is actually causing it.

Arch Linux

#1 2016-11-10 21:24:15

pinentry-curses fails after max-cache-ttl expires

#2 2016-11-11 00:20:13

Re: pinentry-curses fails after max-cache-ttl expires

#3 2016-11-11 00:43:07

Re: pinentry-curses fails after max-cache-ttl expires

#4 2016-11-11 01:10:16

Re: pinentry-curses fails after max-cache-ttl expires

#5 2016-11-11 01:32:24

Re: pinentry-curses fails after max-cache-ttl expires

#6 2016-11-16 21:54:24

Re: pinentry-curses fails after max-cache-ttl expires

Board footer