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 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>).

Only one gpg-agent will be able to access smartcards, the other will
just give an error.

If both `gpg` invocations happened outside a login session, usually
XDG_RUNTIME_DIR wouldn't be set and gpg would always use the same
socket location (unless also invoked from within a session with
XDG_RUNTIME_DIR set).  Or one could set XDG_RUNTIME_DIR to a fixed
location before invoking gpg (or unset it), but gpg ignores that
variable.

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).

Ansgar

this is a deliberate choice by upstream.

how are you launching gpg without a login session?  that's not a common
workflow from what i can tell.

yes, smartcard access is limited to one running scdaemon per machine.

If you're concerned about XDG_RUNTIME_DIR, you should try to re-open
discussion with upstream about it:

https://dev.gnupg.org/T1330

If upstream can't be convinced, and you've got a patch that you think
debian should carry to be more distro-compatible, feel free to propose
it on this bug report.

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?

or are you looking for something else?

Yes, I saw it in the source :-/

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

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

On Mon, 27 Nov 2017 18:24, ansgar@debian.org said:

There is a clear reason for this.  In the past we had lot of troubles
with too freely configurable socket names and file systems which don't
support local sockets.  Recall that GnuPG 2.x goes back to 2003 and it
has always used the local socket and fully relied on it for gpgsm - a
maybe nice application but nevertheless a tool which has been in wide
use since about 2005 by a few large sites.  So with 2.2 removed the
trouble by using a fixed socket dir utilizing the /var/run hierarchy
which is on all known Unices a local file system supporting sockets.
The only overhead a _Unix_ sysadm has to do is putting this into
rc.local:

      [ ! -d /run/user ] && mkdir /run/user
      awk -F: </etc/passwd '$3 >= 1000 && $3 < 65000 {print $3}' \
        | ( while read uid rest; do
              if [ ! -d "/run/user/$uid" ]; then
                mkdir /run/user/$uid
                chown $uid /run/user/$uid
                chmod 700 /run/user/$uid
              fi
            done )

<rant>Unfortunately Debian GNU/Linux is no longer a standard Unix system and
thus long standing things don't work anymore. nohup.</>

On such semi-Unix systems you need to work around their shortcomings; in
your case cron.  Adding yet another thing and in particular XDG, which
more targets the desktop than the server, would make things more
complicate.

However, there is another proposal on the gnupg-devel list to try
another socketdir first.  The suggestion is to try the socket names in
this order:

 1. /var/run/gnupg/user/UID/S.gpg-agent
 2. /var/run/user/UID/gnupg/S.gpg-agent
 3. HOME/.gnupg/S.gpg-agent

The first one would be new.  It has the advantage that systemd does not
know about it and thus can't remove it (and should not because it
belongs to gnupg).  The disadvantage is that systemd does not remove
this directory and gpg-agent can't use the directory removal as trigger
to terminate itself.  However, it is at the discretion of the sysadm to
create such directories in the first place.

The other option would be a global config file to list additional socket
directories to try.  That would a require a bit more code but that shall
not be the problem.

That is not unstable due to gpg but because something removes or creates
directories which are supposed to exist right after system startup or at
least before calling gpg the first time.
it is used, if not ~/.gnupg is used (with all its problems).


Shalom-Salam,

   Werner

Was support for /run/user/<id> around in 2003?  I'm fairly sure that
came a bit later.

How many Unices provide /run/user/<id> and follow the GnuPG semantic
for it?  And how many follow XDG semantics for that path?

That assumes a Real UNIX has rc.local, all user accounts are in
/etc/passwd and only uids in the range [1000, 65000) are used.  I'm
fairly sure systems exist where that is not the case.  But then maybe
those are no standard Unix systems in the GnuPG sense of standard
and/or Unix ;-)

Maybe Debian should then try to move away from GnuPG to something that
works better for its core infrastructure instead of having to work
around GnuPG's shortcomings from only supporting "standard Unix
systems" which apparently doesn't include most widely used Linux
distributions these days...

Using XDG_RUNTIME_DIR or a GnuPG-specific environment variable would
not require root to configure a different location.  The
/run/gnupg/user/<id> proposal does.  If GnuPG will in the future
require root to be configured then be that so.

At least /run/gnupg/user/<id> doesn't assume different semantics for a
path commonly used differently.

Ansgar