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 (j...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
