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

[Eric Dorland]

* josh at joshtriplett.org (josh at joshtriplett.org) wrote:
> 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.

It's not, it's basically an IPC library the binaries use to
communicate with each other. Though there's nothing stopping anyone
from extending it in that direction.

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

Given a recent conversation about socket activation with upstream, I
suspect they would not be receptive to using dbus.

-- 
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20150106/a1a91d1a/attachment.sig>