I have been thinking of fixing epg.el bug #24350
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.

The problem is that in tofu conflicts epg interprets GnuPG's "GET_LINE
tofu.conflict" and waits for user input on minibuffer. The user
interaction is implemented in epg--status-GET_LINE function. But as far
as I can see it can't work. I'll try explain the problem.

Gpg is called with a command-line like this:

    GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 /usr/bin/gpg
    --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --output
    /tmp/epg-output983w_C --verify -- /tmp/epg-signature9839JJ -

Note that "--command-fd 0" expects interactive commands from the file
descriptor 0 (standard input). Such commands are handled by
epg--status-GET_LINE function which is triggered when "--status-fd 1"
output contains GET_LINE command. But also note the "-" at the end of
the command line. It means that the message contents is also being
received from the file descriptor 0 (standard input). Getting both the
message's contents and --command-fd's GET_LINE input from stardard input
stream doesn't work, or so it seems in my tests.

A possible fix: Remove "--command-fd 0" from gpg's options. It looks to
me that it is not really used. Then also epg--status-GET_LINE function
can be removed.

The bug report #24350 also mentions of supporting tofu conflict
resolution. If --command-fd's GET_LINE isn't an option for epg.el what
alternatives are available? Can tofu conflict be handled after the
verifying operation if we collect enough --status-fd's TOFU_STATS
information?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///