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
signature.asc
Description: OpenPGP digital signature
