Hi, some thoughts on this issue, maybe it can stir new ideas.
We can control (kill) the dirmngr using gpgconf --kill dirmngr. We can't kill it just before launching our torified gpg process, however, because there is a risk of race condition (another one could be launched before we actually run our torified gpg). If it's created on-demand by existing gpg process, we could kill it after launching our gpg process and refresh keys to launch a new one (but the race condition issue may still occur if any gpg2 process can launch a dirmngr). If we can find a way to check whether the dirmngr is torified, we could check before refreshing and kill it if it isn't. dirmngr can also be launched explicitly as a daemon, but this is deprecated according to the documentation so we probably don't want to go that way. It can be launched interactively with its own sockets to listen to commands, also : this is, according to the man "only used for testing", but maybe it's possible to take advantage of this mode to launch a dirmngr dedicated to parcimonie. Or we could run gpg with an alternate homedir, all files in it being symlinks to the real homedir except the dirmngr socket (bonus points for dirtiness). That said, it seems Werner is thinking about this problem upstream, by adding --use-tor and --force-tor switches, see http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c091816b4a90d7eea6f8601ec1522a0a006794e8 and http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=b4bc1c8b10c7a794fa108678b80f76366a65c47d (not really implemented yet). Cheers, -- nodens
