2.1.19 testing failures on the debian build daemons

Justus Winter justus at g10code.com
Tue Mar 21 10:24:42 CET 2017


Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Mon 2017-03-20 12:04:39 -0400, Justus Winter wrote:
>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>>
>>> Thanks for this suggestion!  I'm hoping that the test suite would work
>>> in either situation:
>>>
>>>  a) where the build path is short enough, or
>>
>> There is no such thing as a short enough build path.  The days of the
>> test suite using obj/tests/openpgp as GNUPGHOME are long gone.  We are
>> creating one GNUPGHOME per test, sometimes a test creates ephemeral home
>> diretories on its own.
>>
>>> 14661 10:21:44.762330 stat("/run/user/1003", {st_mode=S_IFDIR|000, st_size=100, ...}) = 0 <0.000020>
>>
>> /run/user/1003 is not writable.
>
> yes, i know.  Some build daemons, which use extremely minimalist chroots
> that don't even have /run at all, let alone a writable /run/user/1003 or
> whatever.  Should the test suites fail in those cases?  if so, what
> do you think i should do about getting newer versions of GnuPG in
> debian?  If not, what needs to change?

The test suite now uses longer gnupghomes.  This is a deliberate choice
I made.  Let me clarify my position.

First of all, I must stress that this is not a bug in the test suite.
The documentation does not state anywhere that gnupghomes must be "short
enough" (i.e. strlen (gnupghome) <= sizeof sun_path - 1 ('/') - max
strlen of any socket gpg uses - 1 ('\0')).  Furthermore, GnuPG does not
enforce such a restriction.  So until this changes, I consider the paths
the test suite uses slightly odd but valid.

We are not going to paper over any issues in GnuPG just to make the
tests happy.  Doing so defeats the purpose of testing the software, and
merely hides the real problem, making it pop up at our downstream users.

(E.g. https://notmuchmail.org/pipermail/notmuch/2017/024148.html)

GnuPG 2.x unreasonably restricting the length of gnupghomes, either by
documenting it or simply by failing, is a regression from GnuPG 1.4.

The test suite now relies on 'gpgconf --create-socketdir' to make
arbitrary gnupghomes work.

I believe that the problem of restricting the length of gnupghomes is
orthogonal to what 'gpgconf --create-socketdir' solves (even though
indeed separate socket directories solve it as a side effect), but I
have been unable to convince Werner of that.  So now we have to make
sure that 'gpgconf --create-socketdir' actually works everywhere and
robustly solves this problem too.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170321/9b057a45/attachment.sig>


More information about the Gnupg-devel mailing list