| 1 |
On 11 August 2015 at 19:44, Thomas Kahle <tomka@g.o> wrote: |
| 2 |
> If somebody knows how to configure pinentry curses correctly (in |
| 3 |
> particular with respect to screen/multiplexing and long running |
| 4 |
> sessions, that would be a great help (and wiki addition). |
| 5 |
|
| 6 |
|
| 7 |
I suspect its more a bug in GPG than pinentry, as it appears to be GPG |
| 8 |
which tells pinentry which tty to write to. |
| 9 |
|
| 10 |
And the GPG-Agent appears to keep trying to attach to the original tty |
| 11 |
it was spawned in, instead of the one its being queried in. |
| 12 |
|
| 13 |
An example of this can be seen if you spawn two local terminals, |
| 14 |
authenticate GPG in it with pin-entry, and the hide that terminal |
| 15 |
somewhere for later. |
| 16 |
|
| 17 |
Then, when the agent expires and re-prompts you for a pin, your |
| 18 |
current terminal, instead of getting the "cancelled by user" message, |
| 19 |
you instead get it blocking indefinitely. |
| 20 |
|
| 21 |
Then, you can go hunting for that terminal you originally started and |
| 22 |
authenticated GPG-Agent in, and you might find its suddenly asking for |
| 23 |
input. ( Which may or may not actually be usable ). |
| 24 |
|
| 25 |
^ is a hideous and dangerous bug IMHO. |
| 26 |
|
| 27 |
The only solution I know is consistently viable is ensuring your tty's |
| 28 |
you intend to do pin-entries in have GPG_TTY=$(tty) in their |
| 29 |
environment. |
| 30 |
|
| 31 |
|
| 32 |
|
| 33 |
|
| 34 |
-- |
| 35 |
Kent |
| 36 |
|
| 37 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives