On 07/20/2017 07:49 AM, Andrew Savchenko wrote:
> Some pinentry issues imho if GPG_TTY makes it work, at least it was
> when I hit that half a year ago with this suggested as a solution. It's
> not a solution, it's a workaround, as users need to do something.

This is a documented feature from upstream, mainly on secure systems you
want pinentry to be directed to a specific terminal and not whichever an
application calling gpg is called from, as this can also result in
information leak if a fake pinentry is used etc.

So by default, pinentry is started with the tty that gpg-agent is
started in, which can be a protected environment (even more so with the
possibility of remote gpg-agent, allowing it to run in a protected
sandbox and communicating solely over IPC)

With the graphical pinentries this is a bit different (they are less
secure by design, since they are running on a system with a GUI to begin
with..) , gnome3 one will use some DBUS funkery, whereby gtk+ and qt
ones will be easier to debug as they rely mostly on DISPLAY variable to
trigger. By default a curses pinentry is used as fallback (but that
requires proper GPG_TTY, of which the proper very much can be the
initial tty from the agent)

What I have noticed with regards to git though, but not had time to
debug is that it seems to do something odd with regards to communicating
with the agent to begin with, and possibly spawns an own agent, at least
sufficiently confusing that for smartcard use it fail to access the card
due to locking and needing to re-insert the card.. with similar
mechanism to use it outside of git context again afterwards.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3