[Pkg-gnupg-maint] Bug#709104: Bug#709104: Should not Depends or Recommends gnupg-agent

[josh at joshtriplett.org]

On Mon, Jan 05, 2015 at 11:40:58AM -0500, Daniel Kahn Gillmor wrote:
> On 01/04/2015 07:27 PM, Josh Triplett wrote:
> > On Sun, Jan 04, 2015 at 06:16:34PM -0500, Eric Dorland wrote:
> >> Control: tags -1 wontfix
> >>
> >> * Josh Triplett (josh at joshtriplett.org) wrote:
> >>> Package: gnupg2
> >>> Followup-For: Bug #709104
> >>>
> >>> Another possible alternative that would address this bug: modify the
> >>> existing dependency on gnupg-agent to allow alternative implementations
> >>> of the agent protocol, such as gnome-keyring.
> >>>
> >>> (To respond to an earlier message: gnome-keyring does not "proxy"
> >>> gpg-agent or ssh-agent, it replaces them completely.)
> >>
> >> So to summarize, there's basically two bugs. One is the dependency set
> >> pulled in by pinentry-gtk2, which is better tracked in #753163.
> >>
> >> Given the further coupling of gpg-agent and gpg in 2.1 I don't think
> >> we can relax the dependency.
> > 
> > Fair enough.  Perhaps in a future version of GPG, when GPG manages to
> > factor out a library or two, we can revisit this.
> 
> fwiw, modern versions of gpg has factored out not only three libraries
> (libgpg-error, libgcrypt, and libassuan), but has also defined external
> co- or child-process interfaces for many specific functions (e.g.
> gpg-agent for all secret key material, dirmngr for network interactions,
> and pinentry for user-prompting).
> 
> It's not great: they aren't all factored out in the way that works best
> with the rest of the ecosystem; and they're not all easily replaceable;
> and those that have tried to replace them have had a variety of problems
> doing so cleanly.
> 
> But it's not clear to me that *more* factoring out is needed right now.
>  if anything, i think the idiosyncratic interfaces are the things that
> hinder modularity here.
> 
> Josh, are there specific refactorings that you think are important?  If
> so, feel free to describe them to me (offlist, or on pkg-gnupg-maint
> would be fine); i'd be happy to try to advocate for your suggestions
> upstream.

I very much like that they've factored all the GPG key operations into
gpg-agent, with gnupg just asking gpg-agent to do the work.  However,
other programs should not have to spawn gpg as a child process to talk
to gpg-agent.  There should be a top-level "libgpg" or similar, with no
built-in key functionality, that knows how to talk to gpg-agent and do
key operations.  Anything wanting to work with GPG signatures,
encryption, or any other operation traditionally done by fork/exec of
gpg should instead be able to use libgpg and talk to gpg-agent (without
ever having any key material in-process).  (That's not related to this
bug.)

Is libassuan that library?  Its description doesn't make that very
clear; the descriptions both of libassuan0 in Debian and on the upstream
homepage make it sound like an internal implementation detail.

(Bonus if gpg-agent learns to talk over dbus or similar rather than its
own custom protocol.)

- Josh Triplett