Many packages depend on libgpgme11, which depends on gnupg2, which currently depends on gnupg-agent. gnupg-agent attempts to become the default agent for X11 sessions (potentially interfering with the user's existing agent such as gnome-keyring), and additionally pulls in a giant pile of GUI dependencies via its dependency on pinentry-gtk2. gnupg2 does not require gnupg-agent, nor is it even particularly unusual to have gnupg2 installed without gnupg-agent on many systems. Thus, I'd suggest that gnupg2 should only Suggests gnupg-agent. - Josh Triplett
* Josh Triplett (josh@joshtriplett.org) wrote: In what way does gnupg2 not depend on gnupg? If you want to enter a password into gnupg2 gpg-agent is a requirement.
First, because there exist many uses for gpg2 that do not involve entering a passphrase, such as verification of existing signatures, working with passphraseless keys, or using options like --passphrase-fd. I'd argue that's actually the common case for most people with gnupg or gnupg2 installed. Second, because several other agents exist, such as gnome-keyring, which get pulled in as part of a default desktop install. And third, because libgpgme11 depends on gnupg2, but programs depending on libgpgme11 should not necessarily pull in gnupg-agent, given the above. - Josh Triplett
Hi Josh, Eric, to add my 0.02 Euro Cents: I do believe that gnupg2 should depend on gpg-agent! Rationale: Some users will be suprised by core behaviour of gnupg2 not working correctly in the case of gpg-agent not being installed. About dragging in GUI resources via pinentry: There is pinentry-curses which does not GTK or Qt dependencies. So it does not drag in GUI resources. About gnome-keyring: The the GnuPG core developer Werner Koch considers the hijacking that gnome-keyring does to gpg2 <-> gpg-agent _hostile_ as it degrades the user experience of Gnupg for many. Reference" http://lists.wald.intevation.org/pipermail/gpg4win-devel/2013-July/001253.html " I consider it hostile to hijack the communication between ssh and its ssh-agent. We ain't no gnomes [1]." "[1] gnome-keyring hijacks the communcation between gpg and gpg-agent. It tries to proxy some stuff but that is mostly broken. For some years now we get reports that gpg2 is not working and after a closer inspection we always see that gnome-keyring is the culprit. It is possible to switch this misfeature off but that is not the default." Best Regards, Bernhard
* Bernhard Reiter wrote That's a reason for a Recommends. Not at all a reason for a Depends. As libgpgme11 depends on gpgme2 that means you get that pulled in in every non-interactive setup (like buildds) if you have anything that uses libgpgme11. But perhaps that just means libgpgme will die for goog because everyone replaces it with something that calls gpgme(1.4) directly because of gpgme2's dependencies. Bernhard R. Link
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.) - Josh Triplett
Dear Maintainer, I just ran into the situation that I had to install gnupg2 on a couple of servers and was forced to install font-config, x11-libs and even some true-type-fonts. not to install recommends. If you really really really want to keep gnupg-agent as a Depends please change the pinentry-Depends of gnupg-agent to pinentry-curses and add a Recommends to pinentry-gtk2 or whatever. I do not think that installing pinentry-curses before installing gnupg2 to keep gnupg2 from pulling those libs is really a good idea, this sounds like something I would want my package-manager to take care of. Regards, Johann Hartwig Hauschild
* Josh Triplett (josh@joshtriplett.org) wrote: 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. - Josh Triplett
(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. Regards,
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
* josh@joshtriplett.org (josh@joshtriplett.org) wrote: 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. Given a recent conversation about socket activation with upstream, I suspect they would not be receptive to using dbus.
JFTR the pinentry gtk ridiculosity, addressed in bug #753163, was never fixed in jessie, so upgrading headless servers that e.g. have mutt installed to read a few files in /var/mail/, has caused tons of these completely pointless dependencies to be installed via libgpgme11; or, rather, for libgpgme11 (and programs depending on it) to be removed and remembered as a pariah...
Hi Josip-- I think what you're saying here, when i take away the words that seem intended mainly to inflame the conversation (like "suckage" and "ridiculosity") is that you don't want to be bothered to install pinentry-curses before upgrading from debian oldoldstable to debian oldstable. Am i reading that correctly, or do you have some other concern? I'm sorry to hear that you find that workaround tedious, but i'm personally inclined to spend my time on debian GnuPG packaging focusing on up-to-date systems (read: debian stable, at least) and on requests that offer concrete suggestions for improvment without inflammatory asides. If you've got a concrete suggestion about what should be done in debian jessie (oldstable) now, please spell it out explicitly. Sorry that debian isn't as good as it should be -- i hope we can do better in the future! All the best,
The point isn't that I personally happen not to want to be bothered to do a specific thing; the point is that these kinds of issues get noticed years after the fact. It was prefaced with JFTR, which, while abbreviated, was nevertheless critical in explaining my intent. I'm sorry that you found it to be too inflammatory or felt that I somehow addressed you in particular; I didn't intend that to happen, rather, I wanted to note for posterity what happened in hope that anyone interested enough to read would learn from this history.