Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent"): > 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?
No. It does not do anything after it is finished. Each script mentioned in debian/tests/control simply exits zero and then (according to DEP-8) it's the responsibility of the test runner to delete the tree if it cares. When run under adt-run with a filesystem snapshotting virt server, there is to need (of course) to delete the temporary area, since it's in a filesystem a snapshot which is going to be deleted. > 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) That's not really fast enough. > > 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. Then perhaps it should take a lock. I assume there must be some kind of locking anyway, or concurrent startups would occasionally fail. I propose a design something like this: * When GNUPG_AGENT_LIFETIME_FD is set: - gpg-agent does not create a rendezvous socket. Instead, it selects/polls this fd for reading. - When the fd is readable, gpg-agent expect to receive one end of an AF_UNIX socketpair over it by fd passing. That received fd is treated the same way the answer from accept() would be. - If the master fd signals EOF, gpg-agent exits. - gpg-agent should nevertheless take out a lock on a common name in $GNUPGHOME. * When gpg needs an agent but none is running discoverable in the current global way : If GNUPG_AGENT_LIFETIME_FD is not already set, - gpg creates an AF_UNIX anonymous socketpair. One end will become the "agent" fd and is set ~CLOEXEC. The other end becomes gpg's and is set CLOEXEC. - gpg sets GNUPG_AGENT_LIFETIME_FD to the "agent" end of the socketpair - gpg spawns the agent - Now GNUPG_AGENT_LIFETIME_FD is set. When gpg wants to connect to the agent, it creates a new socketpair and uses sendmsg to pass one end to the agent; it then closes that end and uses the other end as if it had just been connect()ed. * Creating a socketpair and setting GNUPG_AGENT_LIFETIME_FD should be documented as a way to get a privately-scoped gnupg. For example, dgit might like to do this so that it can make its three signatures with one user authorisation and then terminate the authorisation when it is done. The document should say that: - Programs must not set GNUPG_AGENT_LIFETIME_FD if it is already set, so they must check it first. (Otherwise deadlock will occur.) - Programs need not check for the existence of an `ambient' gnupg agent in the user's account/session/environment; if there is one, the GNUPG_AGENT_LIFETIME_FD setting will be ignored. * The result is that the scope of an auto-spawned agent is a single GNUPG_AGENT_LIFETIME_FD (normally, a single gnupg2 gpg program). Other concurrent calls to gpg will block. *  If you don't think this behaviour is good by default, it could be a config option. But I would argue that it ought to be the default is the environment has not provided an agent, because it provides the same authorisation lifetime as was implemented in gnupg1. > > In particular, `gpgconf --kill gpg-agent' should be documented. > > Where would you like it documented? it's in gpgconf(1): In gpg-agent(1) ! > 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 :) For now I have bodged this with a new schroot script /etc/schroot/setup.d/71killagent. Attached. This doesn't solve the problem when the test scripts are run ad-hoc. It won't solve the problem for other programs which set HOME (or GNUPGHOME) as part of test suites or whatever. Thanks for your attention. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
#!/bin/sh set -e . "$SETUP_DATA_DIR/common-data" . "$SETUP_DATA_DIR/common-functions" . "$SETUP_DATA_DIR/common-config" if [ $STAGE = "setup-start" ] || [ $STAGE = "setup-recover" ]; then : elif [ $STAGE = "setup-stop" ]; then info "Stopping gpg agents" chroot "$CHROOT_PATH" start-stop-daemon --verbose --exec /usr/bin/gpg-agent --stop || : fi