On Sat 2017-02-11 14:21:45 -0500, Daiki Ueno wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > >> Back on 2016-06-09, in Message-Id: m3r3c6hgch.fsf-u...@gnu.org on >> gnupg-de...@gnupg.org, >> Daiki Ueno <u...@gnu.org> (cc'ed here) wrote: >> >>>> If the loopback pinentry evolves into general purpose mechanism, I would >>>> rather suggest to remove the Emacs specific stuff entirely. The >>>> rationale is: >>>> >>>> - The immediate motivation behind the Emacs pinentry was that the >>>> loopback pinentry had some limitations when used as a replacement of >>>> gpg1's passphrase prompt, e.g. [1], which was fixed a while ago. >>>> >>>> - Debian seems unlikely to build in the Emacs mode with Pinentry[2]. >>>> That means to add another (non-working) configuration vector and >>>> upstream Emacs cannot rely on that feature[3]. >>>> >>>> What do you think? Is there really anything that can be done better >>>> with the Emacs pinentry than with the loopback pinentry? >>>> >>>> Footnotes: >>>> [1] https://bugs.gnupg.org/gnupg/issue1976 >>>> >>>> [2] https://bugs.gnupg.org/gnupg/issue2034 >>>> >>>> [3] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/epg.el#n607 >> >> Certainly pinentry-emacs isn't going to be distributed by default, since >> there are many more non-emacs users of gpg-agent than there are users of >> gpg-agent. > > I am confused that you quote the above email while it doesn't say > anything about the pinentry-emacs subpackage, but is talking about the > INSIDE_EMACS hack, which is disabled in Debian.
I'm sorry, clearly i'm confused! I thought that pinentry-emacs was "emacs-specific stuff entirely", and therefore it was addressed as well by the e-mail above. What do you think would be the ideal situation with pinentry-emacs, gnupg-agent, "the INSIDE_EMACS hack", and debian? I'm open to proposals about what would make the most sense to support, but i'm also aware that this is a complex ecosystem (even without emacs in the loop!) and the complexity is already the source of numerous bug reports that i've spent time fielding. For example, what's the best way to debug a problem when emacs pinentry isn't working? do we look at gpg? gpg-agent? pinentry? emacs itself? all of those places? What happens when the user has two separate instances of emacs running? What if there's an instance of emacs running and someone uses tramp to connect to a remote ssh server, and gpg-agent is providing the ssh-agent interface? What if someone uses ssh from *outside* of emacs and it talks to a gpg-agent that was auto-launched from within an emacs session? What about when there's an instance of emacs running in a graphical session on a machine where the same user is also logged into the machine via ssh, and they're using a different graphical session? how does pinentry-emacs interact with emacs --daemon and multiple emacsclient instances? you might think these are far-fetched questions, but i think i've run into the equivalent of all of these scenarios for the non-emacs pinentries. I've been reluctant to bring in the additional emacs complexity to the debian pinentry situation because i don't know that i can support it well if there are problems, and i want to focus my debian time on things that i think i can reasonably support. But I would welcome help in providing this kind of support, if we think that having more direct pinentry + emacs integration in debian is the right thing to do. Any suggestions? > By the way, we have been waiting for your response to the upstream bug > for a long time: https://bugs.gnupg.org/gnupg/issue2034 I was unaware that anything was needed from me here. re-reading it, i'm still not sure. Can you help me understand what you need from me?for that bug report? --dkg
signature.asc
Description: PGP signature
