1 |
On 07/20/2017 07:49 AM, Andrew Savchenko wrote: |
2 |
> Some pinentry issues imho if GPG_TTY makes it work, at least it was |
3 |
> when I hit that half a year ago with this suggested as a solution. It's |
4 |
> not a solution, it's a workaround, as users need to do something. |
5 |
|
6 |
This is a documented feature from upstream, mainly on secure systems you |
7 |
want pinentry to be directed to a specific terminal and not whichever an |
8 |
application calling gpg is called from, as this can also result in |
9 |
information leak if a fake pinentry is used etc. |
10 |
|
11 |
So by default, pinentry is started with the tty that gpg-agent is |
12 |
started in, which can be a protected environment (even more so with the |
13 |
possibility of remote gpg-agent, allowing it to run in a protected |
14 |
sandbox and communicating solely over IPC) |
15 |
|
16 |
With the graphical pinentries this is a bit different (they are less |
17 |
secure by design, since they are running on a system with a GUI to begin |
18 |
with..) , gnome3 one will use some DBUS funkery, whereby gtk+ and qt |
19 |
ones will be easier to debug as they rely mostly on DISPLAY variable to |
20 |
trigger. By default a curses pinentry is used as fallback (but that |
21 |
requires proper GPG_TTY, of which the proper very much can be the |
22 |
initial tty from the agent) |
23 |
|
24 |
What I have noticed with regards to git though, but not had time to |
25 |
debug is that it seems to do something odd with regards to communicating |
26 |
with the agent to begin with, and possibly spawns an own agent, at least |
27 |
sufficiently confusing that for smartcard use it fail to access the card |
28 |
due to locking and needing to re-insert the card.. with similar |
29 |
mechanism to use it outside of git context again afterwards. |
30 |
|
31 |
-- |
32 |
Kristian Fiskerstrand |
33 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
34 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |