2.1.19 testing failures on the debian build daemons

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue Mar 21 21:46:56 CET 2017


On Tue 2017-03-21 08:22:41 -0400, Justus Winter wrote:
> Werner Koch <wk at gnupg.org> writes:
>
>> Please come up with a practical fix.
>
> Fixed in 06f1f163e96f1039304fd3cf565cf9de1ca45849.

thanks for this, Justus!  2.1.19-3 (which includes many of the
post-release patches after 2.1.19) is now building again on the debian
build daemons:

  https://buildd.debian.org/status/logs.php?pkg=gnupg2&ver=2.1.19-3&suite=experimental

I'll let that settle in for a day or two and then consider uploading it
to unstable, since it fixes several bugs from 2.1.18.

> In the interest of moving the discussion forward, can we now agree on
> the fact that 'gpgconf --create-socketdir' is not a sufficient solution
> to the problem of overly long socket names?

So we have a few different situations that make predictable socket
locations troubling in a universal sense.  Every possible candidate
location has at least one problem:

 a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
    one that exceeds sun_path length.

 b) $GNUPGHOME/S.gpg-agent : this might be on a remote filesystem or a
    filesystem that cannot support unix-domain sockets (e.g. fat32 on a
    thumbdrive)

 c) anywhere under /tmp : this is not a predictable location that is
    safe to use, and inherently can't be on most systems where /tmp is
    shared and world-writable.

 d) /run/user/$(id -u)/gnupg/S.gpg-agent : We know that this user-owned
    directory isn't guaranteed to be available in every environment,
    including (sadly) chroots that are used by the debian build
    infrastructure.

Justus's clever use of relative paths resolves issue (a) and avoids the
problems associated with (c) and (d), but falls afoul of (b).

Where /run/user exists, using /run/user/$(id -u)/gnupg resolves issues
a, b, and c.  But as (d) points out it doesn't exist everywhere.

If we combine Justus's use of relative paths with the use of
/run/user/$(id -u)/gnupg where possible, then the only corner case we
cannot handle is:

 * $GNUPGHOME is on a filesystem that cannot support unix-domain
   sockets, and /run/user does not exist.

If anyone has a suggestion for how to handle this corner case, i'm all
ears.

        --dkg



More information about the Gnupg-devel mailing list