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

[Daniel Kahn Gillmor]

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.

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.

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
-------------- 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/20170210/b2c639a0/attachment.sig>