[pkg-gnupg-maint] Bug#882736: Bug#882736: gpg-agent: does not always use same socketdir

Ansgar Burchardt ansgar at debian.org
Mon Nov 27 17:24:08 UTC 2017


On Mon, 2017-11-27 at 10:02 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2017-11-26 12:00:31 +0100, Ansgar Burchardt wrote:
> > gpg(-agent) uses a different socketdir when a non-default homedir
> > is
> > specified depending on the environment:
> > 
> > If /run/user/<id> exists, it will use
> > /run/user/<id>/gnupg/d.<hash>;
> > otherwise it will fall back to <homedir>.  XDG_RUNTIME_DIR is
> > intentionally ignored...
> 
> this is a deliberate choice by upstream.

Yes, I saw it in the source :-/

> > This does cause multiple instances of gpg-agent to be launched when
> > first invoking `gpg` with no open login session (/run/user/<id>
> > does
> > not exist) and then again with an open login session open (which
> > created /run/user/<id>).
> 
> how are you launching gpg without a login session?  that's not a
> common workflow from what i can tell.

>From a script invoked from cron.  That doesn't open a logind session. 
sudo would work too.

> > In addition it would be nice if there was an option to explicitly
> > configure a socket directory to allow using supervision for
> > gpg-agent's with a non-default homedir (and not having to rely on
> > implementation details like d.${hash} which might change).
> 
> I don't understand what you're asking for here.
> 
> The socket path used by the clients of the agent should be stable if
> you
> discover the agent's socket path like so:
> 
>    gpgconf --homedir=/wherever --list-dirs agent-socket
> 
> So you should be able to supervise that location, right?

Yes, but that depends on the internal gpg logic to decide where to put
sockets (which is unstable).  If one could tell gpg which directory to
use, one could work around gpg choosing something unstable.

It also requires to call gpgconf to configure the supervisor (and the
location might change at any time in the future so gpgconf needs to be
called always).

(For now I wrked around the problem by having a lingering systemd-
logind session for the service user.  Then /run/user/<id> always
exists.)

Ansgar



More information about the pkg-gnupg-maint mailing list