[pkg-gnupg-maint] Bug#854797: pinentry: Add pinentry-emacs package

[Daniel Kahn Gillmor]

On Sat 2017-02-11 14:21:45 -0500, Daiki Ueno wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>
>> Back on 2016-06-09, in Message-Id: m3r3c6hgch.fsf-ueno at gnu.org on
>> gnupg-devel at gnupg.org,
>> Daiki Ueno <ueno at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170211/6a25880a/attachment.sig>