How to unbreak pinentry-curses in F32

[Sam Varshavchik]

Sharing the following for the benefit of others. Entering a passphrase for  
your gpg key with a passphrase is broken again, if you're on a simple ssh  
connection, from the looks of it.

It originally broke a year or so ago – maybe longer, I don't recall exactly  
-- when the simple prompt for your passphrase was replaced by a separate  
pinentry tool that wanted to open a pretty X window for that. Nobody uses  
ssh anymore, apparently, and checking DISPLAY and falling back to a terminal  
prompt wasn't very obvious, so everyone had to figure out how to do

echo pinentry-program /usr/bin/pinentry-curses >~/.gnupg/gpg-agent.conf

Well, even that no longer works:

$ git tag -s -a libcxx/0.21.0/`date +%Y%m%d%H%M%S` -m 'Tag version 0.21.0'
error: gpg failed to sign the data
error: unable to sign the tag

… aaaand, we're done.

stracing what was going on wasn't very enlightening:

[pid 2581154] read(4, "INQUIRE PINENTRY_LAUNCHED 2581156 curses 1.1.0 -  
gnome localhost:10.0\n", 1002) = 70
[pid 2581154] write(2, "[GNUPG:] PINENTRY_LAUNCHED 2581156 curses 1.1.0 -  
gnome localhost:10.0", 70 <unfinished …>

[ buncha noise, and finally ]

[pid 2581154] read(4, "ERR 83918950 Inappropriate ioctl for device  
<Pinentry>\n", 1002) = 55

And that's it. After reading random man pages, here and there, and simply  
trying things at random, I discovered that setting GPG_TTY environment  
variable makes pinentry-curses work again:

GPG_TTY=`tty` git tag -s [options]

And, pinentry-curses works again. There you go.

Why can't this be an obvious default fallback, so everything works  
flawlessly, by default, for everyone? Would love to hear a logical  
explanation.