Control: forcemerge 830658 834368 Control: retitle 830658 gpg-agent cannot talk to libsecret or X11 when not started from the same session Control: tags 830658 + moreinfo
834368 and 830658 describe basically the same problem: when gpg-agent is started from a different session, from systemd's user services, or from anywhere else, the ssh-agent mimcry fails because it doesn't know how to prompt the user. During the user's X session (possibly at the start of the session), the user can explicitly invoke (as Werner points out in https://bugs.debian.org/834368#20): gpg-connect-agent updatestartuptty /bye Which is documented as: 0 dkg@alice:~$ gpg-connect-agent 'help updatestartuptty' /bye # UPDATESTARTUPTTY # # Set startup TTY and X11 DISPLAY variables to the values of this # session. This command is useful to pull future pinentries to # another screen. It is only required because there is no way in the # ssh-agent protocol to convey this information. OK 0 dkg@alice:~$ This will update not only TTY and X11 but also GTK and DBUS env vars to match whatever's present in the session. You can see the full list with "getinfo std_env_names", the current "startup env" with "getinfo std_startup_env", and the env of the current session (if you're in the middle of one) with "getinfo std_session_env" However, i note that when i use these commands with the systemd-controlled user service while i'm the only logged in user (and i'm logged in only once), i get the following answers for std_startup_env: D DISPLAY=:0 D XAUTHORITY=/home/dkg/.Xauthority D DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus This looks sufficient for pinentry to be able to prompt successfully. DISPLAY points to the right location, and the DBUS_SESSION_BUS_ADDRESS appears to be sufficient for libsecret to get the info it needs. I tested pinentry by hand (for -qt, -gtk-2, and -gnome3) with: echo getpin | env -i DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=/run/user/1000/bus pinentry a longer script on stdin than "getpin" should make it possible to do the same test for libsecret. something like (see "info pinentry" for more details): env -i DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=/run/user/1000/bus pinentry <<EOF option allow-external-password-cache setkeyinfo testkey-for-pinentry getpin EOF and indeed this works for me with pinentry-gnome3 when i have gnome-keyring installed. (it works in that if i run it once and check the pinentry-provided box, gnome-keyring stores the passphrase; if i run it a second time, i don't get the prompt at all, and pinentry tells me: S PASSWORD_FROM_CACHE D abc123 So i'm a bit confused about why the prompting isn't being done correctly for Norbert, and why libsecret isn't connected for Brian. Norbert and Brian, can you report what you see for: gpg-connect-agent 'getinfo std_startup_env' /bye When you have the systemd user service enabled after a clean login? Can you also try this sort of direct debugging of pinentry? Thanks, --dkg
signature.asc
Description: PGP signature
