Package: parcimonie Version: 0.10.2-4 Followup-For: Bug #836266 I suffered from this same problem here on a fresh stretch install: parcimonie rewrote my dirmngr.conf to add use-tor and broke all network operations *outside* of parcimonie.
This is a change of behavior and a significant regression from jessie,
where parcimonie would do its thing on the side and would leave the
default gpg configuration alone for the most part.
While I am sensitive to the argument that *all* gpg network operations
go through tor, I do not think this policy should be *enforced* by
parcimonie, let alone silently and after a non-user-visible
timeout. Having something rewrite a configuration file behind your
back is one of the most troubling and confusing user experiences we
can provide to our users and I believe we should avoid doing that as
much as possible.
"use-tor" should be a *runtime* configuration that parcimonie uses. I do
not care much how this is implemented: it can be a separate dirmngr, or
something that trickles down from the gpg commandline to dirmngr and
reconfigures it on the fly.
I *want* to fetch certain keys *directly*, *not* going through a tor
exit node. There are simple and valid reasons to still be able to do that
while having parcimonie to run in the background, if only to verify
certain key material outside of the tor network.
The fact that dirmngr and gpg have horrible failure modes and error
messages certainly doesn't help here, but shouldn't keep parcimonie from
doing the right thing and not destroy the policies i set in my
configuration.
As things stand now, I see no choice but to stop using parcimonie, which
means:
1. i will not update my keyring in a timely manner anymore, or;
2. i will reveal my keyring social graph to the keyserver and
possible attackers
That seems like the opposite of what parcimonie is trying to
accomplish.
A.
signature.asc
Description: PGP signature
