[Pkg-privacy-maintainers] Bug#836266: parcimonie should not modify the user's dirmngr.conf

[intrigeri]

Hi,

intrigeri (2016-12-06):
> Dear users and fellow maintainers,
>
> I am very much in doubt about what to do with this bug report.
>
> Ideally, I think that parcimonie would start its own dirmngr instance,
> fork the configuration of the default instance, and enable use-tor in
> its own copy. I guess that's doable, but I am not convinced it's worth
> the effort.

I've researched this avenue a bit today and the best design I could
think of is this:

 - Introduce dirmngr-with-tor.{socket,service} user units,
   that only differ from the existing dirmngr.{socket,service} units
   like this:

    - ListenStream=%t/gnupg/S.dirmngr-with-tor
    - ExecStart=/usr/bin/dirmngr --supervised --use-tor

   Additionally, one would need to figure out how what to do with
   "ExecReload=/usr/bin/gpgconf --reload dirmngr".

 - Give gpg(1) a command-line argument to specify which dirmngr socket
   shall be used.

   If there's already a way to do this, that does not require patching
   GnuPG, I'm all ears.

Then, parcimonie-like programs could use that new option to ask gpg(1)
to use the extra, torified dirmngr instance. And parcimonie could stop
modifying the user's dirmngr.conf.

FWIW, while looking for a hopefully simpler fix, I've also thought
about:

 - Use "gpg --dirmngr-program"

   As long as there's already an instance listening on S.dirmngr,
   gpg seems to ignore this. I guess that makes sense.

 - Run "gpg --recv-keys" in an environment where S.dirmngr
   has been replaced by a torified dirmngr's socket.

   I understand that creating such an environment requires one of:

    - a setuid-root helper, such as bwrap

    - root privileges (e.g. to bind-mount stuff) → probably not
      OK in this context

    - user namespaces enabled, which I doubt we can assume in this
      context

    - symlink'ing dance + custom $GPGHOME → sounds fragile and racy

    - kill dirmngr and run our own temporarily → sounds fragile and
      racy

And of course, one should not forget about:

 - anarcat's idea of replacing the "download + validate/filter +
   import" part of gpg --recv-keys's functionality with something
   that does not use dirmngr.

 - Some day, someone will teach dirmngr to do parcimonie's job :)