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

[Florian Margaine]

Hi Daniel,



Le 11 févr. 2017 03:07, "Daniel Kahn Gillmor" <dkg at fifthhorseman.net> a
écrit :

Hi Florian--

On Fri 2017-02-10 08:26:11 -0500, Florian Margaine wrote:
> Adding the pinentry-emacs package can let emacs users enter their PIN
> into emacs' minibuffer itself, along with an emacs package. The source
> is already available, it's just about enabling more options in the
> configure step. I understand that this has been voluntarily disabled,
> but do not understand why, given that it does not cause any
> side-effect, and only helps in providing one more package.

I have not had any near-term plans to add pinentry-emacs to the debian
packaging, because it's not clear to me what it adds that
pinentry-mode=loopback (which is now the default configuration for
gpg-agent) already provides.


Well, to start off, I wasn't aware that this mode existed :-)


That said, after educating myself about this mode, it is not what
pinentry-emacs provides. (More below.)


furthermore, i think that it's generally better security policy to treat
the agent as an oracle, rather than expecting to provide
confirmation/passphrases/whatever in the same channel as the request --
in particular, i want to encourage and enable the use of an agent that
does *not* permit anything like loopback mode, but is instead isolated
>From the requesting process completely.  In that scenario, the
requesting process never sees or handles passphrases or secret keys, and
cannot approve or reject requests; the agent is autonomous and
independent from its client, which allows for stronger isolation and
security guarantees.


This is actually what pinentry-emacs provides. Instead of being a loopback
mode, gpg-agent still queries an external pinentry to get the passphrase.
Pinentry-emacs then communicates with a UNIX socket in
/tmp/emacs$UID/pinentry, on which a daemon is listening. This daemon is run
from emacs, and queries the user for the passphrase.

The use case is the following: I am using a terminal inside emacs, I run an
operation calling gpg-agent, and gpg-agent will query the emacs instance
through the UNIX socket. (In my case, I am using the emacs instance as a
window manager, so it makes perfect sense to ask the passphrase through it.)

Generally speaking though, pinentry-emacs provides a different
functionality than what loopback mode does, from my understanding (emphasis
there, I am happy to be proven wrong), so it makes sense to provide it as a
separate package. (Obviously not by default, like the other pinentry-*
packages.)


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.

But if you or Daiki Ueno has other suggestions or plans about the future
of this functionality, i'm happy to reconsider this within debian.  Any
thoughts?

Regards,

        --dkg


Regards,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170211/dbb55d01/attachment.html>