2.1.19 testing failures on the debian build daemons

[Daniel Kahn Gillmor]

On Wed 2017-03-22 03:02:42 -0400, Werner Koch wrote:
> On Wed, 22 Mar 2017 05:21, dkg at fifthhorseman.net said:
>
>> Putting this in rc.local won't fix the situation where there's a chroot
>> (which is the case for many debian build daemons, and probably other
>
> Setting up a chroot or jail is a complex operation and adding something
> to rc.local is not different than to make sure the required devices and
> tools are all accessible.  Think /dev/random, /etc/hosts etc.

Yes, i agree.  There are many complex environments that people use to
set up chroots or jails for building software, and they have a set of
idiosyncratic nuances that they need to support.

Not all of them currently mandate the creation of per-user directories
(or filesystems) in /run/user/$(id -u).

I've started the process of proposing such a change for schroot in
particular (https://bugs.debian.org/858466), but there are many other
similar systems that might be relevant.

In the meantime, do we want to say that all of those build environments
that don't create /run/user/$(id -u) are not approved for building
GnuPG?  or do we want to try to make it work?

> That is right.  However, we are talking about GnuPG's test suite, aren't
> we?

I think we're talking about any software build/test process that might
invoke GnuPG at some point.  right?

> For other software using
>
>   GNUPGHOME=/tmp/$mydir gpg-agent --daemon testshell
>
> is suitable approach.

Is this documented somewhere for software that depends on GnuPG?  The
use of a statically-named /tmp/$mydir doesn't seem safe, since someone
else could already own that directory.  So maybe we should encourage the
use of mktemp -d explicitly?

And we probably want to ensure that the cleanup happens too, so that'd
be something just a bit more complicated, like:

-----
WORKDIR=$(mktemp -d /tmp/gpg.XXXXXXXX)
GNUPGHOME=$WORKDIR gpg-agent --daemon testshell
…
rm -rf "$WORKDIR"
-----

And what should we do for software that depends on GnuPG but doesn't
know it?  For example, software that relies on a PAM stack which might
include some gpg-related PAM module, or software that links to a library
that itself builds optionally against libgpgme, or software that calls
other potentially-GnuPG-dependent software during a test suite?  How
should we reach those software developers?

The more that we can get GnuPG to "Just Work"™ without any additional
requirements or interactions, the less likely GnuPG is to break the
build processes of these other tools.

We don't want to discourage developers from depending on GnuPG, right?

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170322/c9a2a034/attachment.sig>