2.1.19 testing failures on the debian build daemons
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Mar 21 22:43:49 CET 2017
On Tue 2017-03-21 17:28:36 -0400, Peter Lebbing wrote:
> I hope my comments help with the perspective. If not, never mind.
> On 21/03/17 21:46, Daniel Kahn Gillmor wrote:
>> a) $GNUPGHOME/S.gpg-agent : this might have a particularly long name,
>> one that exceeds sun_path length.
> Has this actually ever been an issue for someone? I understand the
> problem can be artificially induced, but has anyone ever reported
> hitting the limit accidentally?
Yes. I've seen the problem get hit repeatedly by software that depends
on GnuPG, and has a test suite that happens to be reasonably scoped.
Usually GnuPG itself is masked by one or two other layers of software
(e.g. gpgme, perl's GnuPG::Interface, etc) so even extracting the error
messages in a sane way isn't straightforward. it just looks like
arbitrary test suite failures for someone who builds their software in
/home/users/mary/dayjob/software/open-source/libfoo-3.22, but no
failures for the developer who builds in /home/amy/src/foo.
It's a real concern, and this kind of idiosyncratic failure frustrates
developers who are trying to depend on GnuPG.
>> 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.
> What's the problem when it is a sticky directory and you create a
> directory with mode 0700 under it? I think OpenSSH's agent uses it.
The key word in (c) is "predictable".
The problem is communicating the location of the socket to use to the
clients. If i'm a client using some particular GNUPGHOME, how do i find
the sockets of the associated agent? We've tried the environment
variable approach (which OpenSSH's ssh-agent uses) and found a series of
problems with that -- how do you communicate that variable to each
client if you only start the agent later?
Also, gpg 2.1.x has a one-gpg-agent-per-GNUPGHOME model (and
one-dirmngr-per-GNUPGHOME) today, thanks to the "standard-socket". I
don't know whether having two gpg-agents or two dirmngrs interacting
with the same GNUPGHOME will run into contention.
> If /tmp is safe after all, that seems like a good alternative.
how do you solve the predictability problem?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Gnupg-devel