GPG homedir path length limit

[Daniel Kahn Gillmor]

On Thu 2017-02-16 11:51:07 -0500, Werner Koch wrote:
> So that the /var/run/user/ directory is not cluttered with many
> directories.  Setting a different GNUPGHOME is an exception and thus it
> is fine to require an explicit creation.  Remember that not /var/run
> does not need to be a temporary directort - there is more than Linux in
> this world.

If it's an exception, it's infrequent.  So by definition, we won't be
cluttering /run/user/$(id -u)/gnupg/ with many directories.

If we clean up the directories automatically as i recommended when the
daemons terminate, it won't leave a cluttered residue.

The one common work pattern that this misses is this one:

 * create a temporary GNUPGHOME for experimentation
 * when done, do:   rm -rf "$GNUGHOME"

Without the socketdir creation, the daemons will work as long the path
is short enough, and they terminate cleanly when the temporary homedir
is destroyed.

With the socketdir creation, the daemons will work regardless of the
path length, but they won't terminate cleanly if the temporary homedir
is destroyed.  That would be unfortunate.

So my current proposal for GNU/Linux systems for daemons like gpg-agent
and dirmngr when using a non-standard $GNUPGHOME is:

  * daemons create the ephemeral socketdir automatically if possible.
  * clients try the ephemeral socketdir first, then fall back to
    in-$GNUPGHOME sockets (i think this is already the case).
  * daemons watch the $GNUPGHOME with inotify, and auto-terminate if the
    $GNUPGHOME itself is destroyed.
  * daemons try to rmdir() on the ephemeral socketdir on termination,
    failing quietly on ENOTEMPTY.

I've documented this as a bug report at:

   https://bugs.gnupg.org/gnupg/issue2964

>> I personally like the simplicity and uniformity of "if /run/user/$(id
>> -u)/ exists and is writable, then we will use it for the socketdir."
>
> That is non-portable.

What's non-portable about it?  If it's not possible to create the
directory, we don't create it, and fall back to trying locally.  if it
is possible, we do create it and use it.

This thread should probably move over to gnupg-devel at some point, i
guess...

   --dkg