[pkg-gnupg-maint] Bug#834368: gpg-agent's ssh-agent functionality

[Daniel Kahn Gillmor]

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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160829/c2bac21a/attachment-0002.sig>