[pkg-gnupg-maint] Bug#840669: Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Daniel Kahn Gillmor]

Hi Ian--

Thanks for this note, there's a lot in here.

On Thu 2016-10-13 12:47:14 -0400, Ian Jackson wrote:

> The dgit test suite involves setting up a dummy home directory with
> some dummy keys and making and verifying some dummy signatures.  There
> is one of these per test.
>
> When the test suite is run under adt-run --- adt-virt-schroot, the
> agents are automatically started but nothing kills them.
>
> This results in problems: schroot cannot unmount the chroot and cannot
> clean up properly.
>
> I haven't checked but I am pretty sure that if I run the test suite
> natively with gnupg2, it will leak enormous numbers of gpg agent
> processes.

Right, i can see why this might be a problem :)

Does your test suite delete its test homedirs after it is finished?  If
not, would you be willing to include removal of the test homedirs as
part of the tests, or as a final post-test cleanup phase?

I ask because upstream intends for gpg-agent and dirmngr to
auto-terminate when their sockets are removed, and those patches have
been backported into 2.1.15-4 (see
debian/patches/0015-agent-Terminate-on-deletion-of-the-socket-file-Linux.patch
and
debian/patches/0016-dirmngr-Terminate-on-deletion-of-the-socket-file-Lin.patch
).

However, hmm, this doesn't seem to work properly; i just tested with:

    export GNUPGHOME=$(mktemp -d)
    gpg-connect-agent 'getinfo pid' /bye
    rm -rf "$GNUPGHOME"
    sleep 1
    pidof gpg-agent

I've just reported this problem upstream:

    https://bugs.gnupg.org/gnupg/issue2756

One thing worth observing is that if the agent's socket is deleted, it
will eventually terminate itself after a minute or two anyway.  This
will happen even without inotify (but obviously the inotify trigger
should really work to automate cleanup on platforms that support inotify)

> IMO: there should be a way to get gnupg2 to do everything synchronously;
> that is, if it needs an agent, to spawn one which does not listen on a
> socket, but rather just has an existing connection to its parent and
> which will die when the parent does.

This could potentially complicate the agent -- at the moment, i think
the agent expects to be the only process dealing with
$GNUPGHOME/private-keys-v1.d/, and that means that two gpg processes
using this approach could potentially trample on each other.

> Also gpg agent processes should automatically exit if their HOME
> ceases to exist (or if they cease to be the process listening on their
> socket for some other reason)

yes, this is upstream's intended behavior, and it happens (after some
delay), but it's not instantaneous.  Getting the inotify stuff fixed
will make it much closer to instantaneous.

> This problem, and how to deal with it, should be better documented.
> (I looked in gpg-agent(1).  I searched for "agent" and didn't find
> any information that looked helpful; I did find information that
> suggests that `drmngr' may be troublesome too.)  NB gpg-agent(1)
> refers to gpg2(1) and gpgsm(1) which do not exist.

The reference to gpg2(1) is an error, and i've sent a patch upstream to
gnupg-devel.  gpgsm(1) is correct, but you probably don't have the gpgsm
package installed.

> In particular, `gpgconf --kill gpg-agent' should be documented.

Where would you like it documented?  it's in gpgconf(1):

       --kill [component]
              Kill the given component.  Components which support killing  are
              gpg-agent  and scdaemon.  Components which don't support reload‐
              ing are ignored.  Note that as of now reload and kill  have  the
              same effect for scdaemon.

If you can suggest what the text should say and where a reasonable
person might look for it, i'll happily write a patch and encourage its
adoption by upstream.

> NB that I don't think that expecting the dgit test suite to run
> `gpgconf --kill-agent' after every test is reasonable.  Currently
> there is _no_ code for running a specific positive command after
> running a test.  Given the nature of test suites and indeed the nature
> of error handling on posix systems, it's not clear that such a thing
> would be sensible.

If you're not willing to do *anything* (including deletion of the
temporary $GNUPGHOME or some sort of session termination event) upon
completing the test suite, but before tearing down your builder
instance, then i don't know if there's a solution.  But at the moment i
suspect getting the inotify stuff fixed is the sanest and simplest
approach on the platform you and i probably care most about :)

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161014/1236d94c/attachment.sig>