tl;dr - pinentry (in particular pinentry-gnome3) stopped working, pinentry-emacs didn’t work well with daemon mode, just use pinentry-gtk or pinentry-qt5.

This post outlines a shallow dive into a rabbit hole for a broken pinentry setup w/ Emacs – if your setup is already working, skip this.

What is pinentry?

When a program like Gnu Privacy Guard (AKA GnuPG, gpg) requires user input, but that entry has to be secure (and possibly access system password stores/keychains), how do they do it?

Well in general all programs could individually implement this functionality, or they could depend on another program to do it for them. Most robust programs will do both (make it possible to pass the values, and provide some extendability).

pinentry is that program.

What is Emacs?

Just kidding – surely you know what Emacs by now if you’ve been reading this blog.

If this is the first time you’re hearing of emacs, give it a try (after going through the tour)!

Why was my emacs + pinentry setup broken?

It took me a while to figure this out, but what was broken wasn’t the combination of these two tools, it was a single subtool of pinentry – the GUI provided by pinentry-gnome3.

All of a sudden my commits from magit (an incredibly good Git porcelain for emacs) were broken and I couldn’t figure out why – the point at which the prompt for my GPG password would normally pop up wasn’t.

It turns out that pinentry-gnome3 wasn’t working –

False solution #1: Installing pinentry-emacs

I tried a couple things, including installing pinentry-emacs with setup like this in my ~/.emacs:

(require 'epg)
(require 'pinentry)
(setq epa-pinentry-mode 'loopback)
(setq epg-pinentry-mode 'loopback)
(pinentry-start)

This also required enabling a few things in my gpg-agent configuration (~/.gnupg/gpg-agent.conf):

# Allow clients like emacs to get the password themselves then push to GPG
# (for this to work with Emacs, set epa-pinentry-mode to 'loopback in Emacs)
allow-emacs-pinentry
allow-loopback-pinentry

This worked, but it didn’t work well with Emacs running in daemon mode. Often the prompt would go to the wrong window, and the window I was actualy in would be stuck waiting for a prompt that would never get filled out.

The solution: Use another pinentry GUI (ex. pinentry-qt5, pinentry-gtk)

It turns out that the default pinentry GUI program that comes with Arch is pinentry-gnome3 (though there are others!) – and the actual solution was just to *use a different GUI sub-program with pinentry:

In my ~/.gnupg/gpg-agent.conf:

# File re-created by pEp
# See backup in '/home/mrman/.gnupg/gpg-agent.conf.2.pep.bkp'

# File re-created by pEp
# See backup in '/home/mrman/.gnupg/gpg-agent.conf.1.pep.bkp'

# File re-created by pEp
# See backup in '/home/mrman/.gnupg/gpg-agent.conf.0.pep.bkp'

default-cache-ttl 3600
default-cache-ttl-ssh 3600
max-cache-ttl 999999

# NOTE: the emacs pinentry stuff *used* to be here :)

pinentry-program /usr/bin/pinentry-qt5
#pinentry-program /usr/bin/pinentry-gtk

After changing this the diaglogs popped up right when they should, in the right emacs windows.

Wrapup

Hopefully this post saves someone who is looking for a possible solution some time in finding a reasonable workaround!

For me at least there’s no reason to use pinentry-gnome3 (in fact, I avoid almost all Gnome applications unless there’s a specific reason to use it – XFCE is my preferred), so the solution was just as easy as not depending on pinentry-gnome3