Kevin Kofler via devel writes:
Sam Varshavchik wrote: > But, for some reason that I do not understand, the existing terminal > interface always gets broken. Well, how prompts in terminal emulator sessions in the GUI should work is a design decision. Some people (like you, apparently) expect them to behave the terminal way (so the isatty check is the right one for them), whereas others expect them to behave the GUI way (so the code checks whether a GUI agent is running, and only falls back to a TTY prompt if there is none in scope – not sure whether GPG gets this right, but most agent interfaces are implemented like that).
If, and if, it actually behaved this way, and actually worked as advertised, I would not object to entering my password into a popup dialog.
But it never worked this way. Perhaps because the terminal session is an ssh session from another host. Now, you aren't going to start an agent on the host I'm ssh-ing from (and who's to say that the origin host even has an X session, it does in my case but that's not guaranteed either), even with X forwarding. X forwarding can't do that. And starting an agent on the headless server I've ssh-ed into is not going to accomplish anything.
And just to make sure that things haven't changed since the last time I wrestled with this: they haven't. I moved gpg-agent.conf out of the way, made sure that no stray gpg-agent processes are anyway. End result:
mrsam@jack ~]$ gpg --sign z [one minute delay] gpg: signing failed: Timeout gpg: signing failed: TimeoutFound a gpg-agent process running at this point. What it was doing, for a minute or so, who knows. Maybe it's trying to pop up a dialog on the headless server I've ssh-ed into, instead of actually looking at DISPLAY that tunnels X over the ssh connection.
Even if I unset DISPLAY before running "gpg --sign z", it still hangs for about a minute, before deciding that whatever it's doing doesn't work and then runs pinentry-curses to prompt for the password. It does so rather rudely, taking over the entire terminal, but at least it gets restored afterwards.
I haven't looked at the code, so I have no idea if it's technically impossible, for some reason, to simply check DISPLAY, and if unset fallback to pinentry-curses immediately, instead of standing around and looking at each other. That's the very first though that occured to me, when this whole thing broke: should just do that.
But, anyway, before all this jazz with gpg-agent things just …worked. I ran gpg, it prompted for the password, I typed it in, and it was a done deal. Sadly for things to remain simple and work by default is out of fashion now. It's quite acceptable now for things suddenly break one fine day, until I waste away the whole day plumbing the depth of Google to find out I have to drop an explicit
pinentry-program /usr/bin/pinentry-cursesinto ~/.gnupg/gpg-agent.conf in order for thing to continue limping along, as they did before.
Attachment:
pgpDxCW6_5CIB.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
