2.1.19 testing failures on the debian build daemons
Werner Koch
wk at gnupg.org
Tue Mar 21 11:33:33 CET 2017
On Tue, 21 Mar 2017 10:24, justus at g10code.com said:
> The test suite now uses longer gnupghomes. This is a deliberate choice
I doubt that the need for long names for gnupghome just for testing is
justified. In fact it is important to run test on a _local_ file
system. This is the reason why switched to /var/run. Now, when we
encountered problems creating a gnupg socket directory below /var/run we
should do the sensible thing, which is to fallback to standard Unix
behavior of having /tmp mounted locally.
> I believe that the problem of restricting the length of gnupghomes is
> orthogonal to what 'gpgconf --create-socketdir' solves (even though
We are using sockets for communication between the parts of GnuPG since
2002. That are 15 years with only little trouble on some platforms.
The limited length of a socket file has never been a problem in
practice. Well, things sometimes didn't build out of the box, but
moving the build to tmp has always been an option which has been in
active use for more than a decade, for example on some AIX
installations.
Note also that even GnuPG 1.x versions made use of sockets: For the EGD
and the Quintuple-agent (passphrase caching before gnupg 2.0)
ssh-agent also uses sockets without practical problems. Bind and other
daemons have been using sockets for control operations for even longer
than ssh exists. Stevens has enough example on how to use sockets and
warns about the limitations. ustar, the only common tar standard, limit
the lengths of file names as well.
Please come up with a practical fix.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170321/f9ff1abd/attachment.sig>
More information about the Gnupg-devel
mailing list