2.1.19 testing failures on the debian build daemons

[Peter Lebbing]

On 21/03/17 22:43, Daniel Kahn Gillmor wrote:
> It's a real concern, and this kind of idiosyncratic failure frustrates
> developers who are trying to depend on GnuPG.

Clear as rain. I didn't know that.

> The key word in (c) is "predictable".

Isn't this conflating two separate cases?

If the software being built in
/home/users/mary/dayjob/software/open-source/libfoo-3.22 wants to share
the GnuPG installation of mary, it will not set a GNUPGHOME itself and
look for sockets in predictable locations, like /run/user, for the agent
running for user mary. GNUPGHOME is then just as short as usual for mary.

If the software being built in
/home/users/mary/dayjob/software/open-source/libfoo-3.22 wants its own
GnuPG installation, with say specific .conf files and keyrings, it can
set a GNUPGHOME to /tmp/foo-gpg-home-Na1FYAjrLo and create a socket
there, fixing a) and b).

In fact, in general I wonder if it is a good idea to even look in the
predictable places at all when an explicit GNUPGHOME has been set. It
could then find an agent running with a different GNUPGHOME, and
encounter a completely different set of private keys (and different
settings in gpg-agent.conf) from what it has in its own GNUPGHOME.

> 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?

Why is it a good idea to run a single agent for multiple GNUPGHOMEs?

If it's not a good idea to run a single agent for multiple GNUPGHOMEs,
couldn't you just have a regular file in the GNUPGHOME that points out
where to find the socket?[1] It could automatically be created by an
agent that started without finding that file. There's a bit of raciness
there, but it seems solvable. But I get the feeling the purpose of this
whole exercise is to have a single agent running for a single user,
despite multiple GNUPGHOMEs some of which are actually test suites
running during a compilation. I don't really understand why.

(By way of clarification, I mean: GNUPGHOME is standard ~/.gnupg? Look
at standard locations like /run/user. GNUPGHOME something else? Look for
file with socket location in GNUPGHOME).

My 2 cents,

Peter.

[1] In the case of an ephemeral GNUPGHOME, like with test suites, it
makes more sense to just put the socket in GNUPGHOME and GNUPGHOME in /tmp.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170322/1ac2b877/attachment-0001.sig>