Hi Daniel,
Le 11 févr. 2017 03:07, "Daniel Kahn Gillmor" <d...@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-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. 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
