On Wed 2015-09-23 15:10:10 -0400, nodens wrote: > 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).
the usual way to deal with this is just to update the dirmngr config file to have the parameters you want. You can even do that programmatically with gpgconf, for example: echo disable-ldap::1 | dirmngr --change-options dirmngr see gpgconf(1) for more details. you may also be interested in the --runtime flag. > 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). this sounds not only risky but dirty -- the ~/.gnupg directory contains things like lockfiles and tempfiles, which seems like it could go badly wrong if the directories are shared. > 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 This would be the best outcome, i think, and i'm glad to see that Werner is making progress on it. Doing it right appears to depend on tor itself implementing support for a wider range of DNS records. However, doing it more weakly (e.g. dirmngr ignoring SRV lookups and just doing raw A record lookups for the keyserver) seems like it shouldn't be too bad. Hopefully this will land upstream before 2.1.9, and we can try it out. --dkg
