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

[Werner Koch]

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

>> this is a deliberate choice by upstream.
>
> Yes, I saw it in the source :-/

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.

> 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

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

The directories are fixed and won't change: Iff /var/run/user/UID exists
it is used, if not ~/.gnupg is used (with all its problems). 


Shalom-Salam,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20171127/e1e6da37/attachment.sig>