<div dir="auto"><div>Hi Daniel,<div dir="auto"><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 11 févr. 2017 03:07, "Daniel Kahn Gillmor" <<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a>> a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Florian--<br>
<br>
On Fri 2017-02-10 08:26:11 -0500, Florian Margaine wrote:<br>
> Adding the pinentry-emacs package can let emacs users enter their PIN<br>
> into emacs' minibuffer itself, along with an emacs package. The source<br>
> is already available, it's just about enabling more options in the<br>
> configure step. I understand that this has been voluntarily disabled,<br>
> but do not understand why, given that it does not cause any<br>
> side-effect, and only helps in providing one more package.<br>
<br>
I have not had any near-term plans to add pinentry-emacs to the debian<br>
packaging, because it's not clear to me what it adds that<br>
pinentry-mode=loopback (which is now the default configuration for<br>
gpg-agent) already provides.</blockquote><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, to start off, I wasn't aware that this mode existed :-)</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">That said, after educating myself about this mode, it is not what pinentry-emacs provides. (More below.)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
furthermore, i think that it's generally better security policy to treat<br>
the agent as an oracle, rather than expecting to provide<br>
confirmation/passphrases/<wbr>whatever in the same channel as the request --<br>
in particular, i want to encourage and enable the use of an agent that<br>
does *not* permit anything like loopback mode, but is instead isolated<br>
>From the requesting process completely.  In that scenario, the<br>
requesting process never sees or handles passphrases or secret keys, and<br>
cannot approve or reject requests; the agent is autonomous and<br>
independent from its client, which allows for stronger isolation and<br>
security guarantees.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Back on 2016-06-09, in Message-Id: <a href="mailto:m3r3c6hgch.fsf-ueno@gnu.org">m3r3c6hgch.fsf-ueno@gnu.org</a> on<br>
<a href="mailto:gnupg-devel@gnupg.org">gnupg-devel@gnupg.org</a>,<br>
Daiki Ueno <<a href="mailto:ueno@gnu.org">ueno@gnu.org</a>> (cc'ed here) wrote:<br>
<br>
>>    If the loopback pinentry evolves into general purpose mechanism, I would<br>
>>    rather suggest to remove the Emacs specific stuff entirely.  The<br>
>>    rationale is:<br>
>><br>
>>    - The immediate motivation behind the Emacs pinentry was that the<br>
>>      loopback pinentry had some limitations when used as a replacement of<br>
>>      gpg1's passphrase prompt, e.g. [1], which was fixed a while ago.<br>
>><br>
>>    - Debian seems unlikely to build in the Emacs mode with Pinentry[2].<br>
>>      That means to add another (non-working) configuration vector and<br>
>>      upstream Emacs cannot rely on that feature[3].<br>
>><br>
>>    What do you think?  Is there really anything that can be done better<br>
>>    with the Emacs pinentry than with the loopback pinentry?<br>
>><br>
>>    Footnotes:<br>
>>    [1]  <a href="https://bugs.gnupg.org/gnupg/issue1976" rel="noreferrer" target="_blank">https://bugs.gnupg.org/gnupg/<wbr>issue1976</a><br>
>><br>
>>    [2]  <a href="https://bugs.gnupg.org/gnupg/issue2034" rel="noreferrer" target="_blank">https://bugs.gnupg.org/gnupg/<wbr>issue2034</a><br>
>><br>
>>    [3]  <a href="http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/epg.el#n607" rel="noreferrer" target="_blank">http://git.savannah.gnu.org/<wbr>cgit/emacs.git/tree/lisp/epg.<wbr>el#n607</a><br>
<br>
Certainly pinentry-emacs isn't going to be distributed by default, since<br>
there are many more non-emacs users of gpg-agent than there are users of<br>
gpg-agent.<br>
<br>
But if you or Daiki Ueno has other suggestions or plans about the future<br>
of this functionality, i'm happy to reconsider this within debian.  Any<br>
thoughts?<br>
<br>
Regards,<br>
<br>
        --dkg<br>
</blockquote></div><br></div><div class="gmail_extra" dir="auto">Regards,</div><div class="gmail_extra" dir="auto">Florian</div></div></div>