2.1.19 testing failures on the debian build daemons

[Daniel Kahn Gillmor]

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?

    --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/20170321/69a3abad/attachment.sig>