[pkg-gnupg-maint] Bug#830658: Bug#830658: gpg-agent: cannot talk to libsecret when started from systemd

[Daniel Kahn Gillmor]

Control: retitle 830658 gpg-agent: cannot talk to libsecret when used as ssh-agent and not started from the same session
Control: tags 830658 + help upstream

Hi Brian--

On Sat 2016-07-09 18:58:43 -0400, brian m. carlson wrote:
> The recommended way to use gpg-agent, according to README.Debian, is to
> use systemd to start it automatically in the session.  However, when
> doing that, the agent does not inherit $DISPLAY.  This prevents dbus,
> and hence the libsecret integration in pinentry-gnome3, from working.
> Since my passphrases are stored in my desktop's keyring integration, I
> can't use my SSH keys:
>
> genre ok % ssh -oGSSAPIAuthentication=no castro
> sign_and_send_pubkey: signing failed: agent refused operation
> sign_and_send_pubkey: signing failed: agent refused operation
> Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
>
> A dump of the environment from such a gpg-agent process follows:
>
> HOME=/home/bmc\0LANG=en_US.UTF-8\0LOGNAME=bmc\0PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\0SHELL=/bin/zsh\0TEMP=/tmp/user/1000\0TEMPDIR=/tmp/user/1000\0TMP=/tmp/user/1000\0TMPDIR=/tmp/user/1000\0USER=bmc\0XDG_RUNTIME_DIR=/run/user/1000\0MANAGERPID=2813\0
>
> As you'll notice, it's lacking the most rudimentary X environment
> variables.

Thanks for this report (and sorry for the delay in response).

This isn't a problem for the normal uses of gpg-agent (whether started
in-session, via systemd, or even in a separate session), because gpg
knows to send gpg-agent X11 and dbus session credentials on each use.

It's a problem when gpg-agent is used as ssh-agent, because the
ssh-agent protocol doesn't have any way to transmit these configuration
preferences.  This isn't just true for systemd-managed services, it's
also true for a gpg-agent used across concurrent sessions (i.e. started
in session A and then accessed from session B).

So i'm not sure what the right approach is here; there's something of an
impedence mismatch between OpenSSH's agent and GnuPG's agent, and having
one pretend to be the other ends up with this sort of friction.

By "impedence mismatch" i mean things like the following:

 * ssh-agent expects to be run ephemerally, with basically no access to
   the filesystem other than to launch ssh-askpass when needed, and gets
   its keys after each initialization by explicit handoff from the user.
   gpg-agent expects to read and manage its ~/.gnupg/private-keys-v1.d
   directory (where its secret key material is stored) and spawns
   scdaemon (if needed/installed) in addition to spawning pinentry.

 * ssh-agent is configured at process initialization about how and where
   to prompt for confirmation, and is configured at key-load about
   whether to prompt for the use of a given key.  gpg-agent is
   configured at *use* time about how and where and whether to prompt
   for the use of a given key.

Their associated non-daemonized tools (at least gpg and ssh) make some
assumptions about these patterns.

I'd welcome help in resolving this, but i'm not sure what the right
thing to do is.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160805/81bf3f36/attachment-0003.sig>