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

[Ansgar Burchardt]

On Mon, 2017-11-27 at 20:30 +0100, Werner Koch wrote:
> 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.

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?

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

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

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

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

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

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