On Thu 2019-08-08 23:17:00 -0400, Antoine Beaupré wrote: > So if I could rephrase that bug, I'd say that gpg-agent is > "sticky". Whenever it gets called first is what determines the TTY. If > that TTY is messed up (because it gets called too early in the session), > it's forever doomed and needs to restart or be retold where it is: > > gpg-connect-agent UPDATESTARTUPTTY /bye > > This seems sub-optimal. It's also quite strange it affects only > authentication and not signing: it might be something specific to > gpg-agent's SSH support.
it is. gpg-agent's SSH support uses OpenSSH's ssh-agent protocol, which
has no way of indicating to the agent how/where the prompts should
happen.
gpg-agent's native mechanism uses an entirely different protocol (on a
different socket too). The gpg-agent mechansism *does* provide a way
for the invoking client to tell the agent where the prompting should
happen. This means that when gpg itself talks to gpg-agent, it sets the
DISPLAY, DBUS_SESSION_BUS_ADDRESS, GPG_TTY, etc. options explicitly.
But when ssh talks to what it thinks is the ssh-agent, it provides no
such information.
If you use a graphical environment with a per-user dbus session which is
initialized with the rest of your systemd user session manager, then you
should also use a pinentry that communicates over dbus -- in this case,
gpg-agent should be started with knowledge of the dbus session, and so
the pinentry should automatically know how to communicate with the user.
afaik, pinentry-gnome3 is the only pinentry that communicates over dbus
at the moment.
so, the recommended way of avoiding these problems longer term on a
system with a graphical environment is (as the superuser):
apt install pinentry-gnome3 dbus-user-session
update-alternatives --set pinentry /usr/bin/pinentry-gnome3
and then log out and log back in again.
If that doesn't work for you, i'd definitely like to know about it.
--dkg
signature.asc
Description: PGP signature
