[Pkg-privacy-maintainers] Bug#780628: Bug#780628: parcimonie: support gpg2

[Daniel Kahn Gillmor]

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