Hi Florian-- On Sat 2017-02-11 07:18:05 -0500, Florian Margaine wrote: > That said, after educating myself about this mode, it is not what > pinentry-emacs provides. (More below.)
thanks for this discussion!
> 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.
/tmp/emacs$UID/pinentry is not a sensible choice of paths, since it is
within a world-writable directory (/tmp). Ephemeral communications
sockets like this belong in /run on a modern GNU/Linux system.
> 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.)
I see -- your use case makes sense to me, but we can agree that the
overwhelming majority of uses of emacs do *not* meet this pattern,
right? If pinentry-emacs is enabled during the build, it looks to me
like it affects the fallback modes for graphical agents that can't find
access to their graphical display as well. If i trigger something in
emacs that triggers something that invokes gpg, at what point should my
normal graphical agent decide to fall back to this emacs mode?
are there any circumstances where anything spawned by an emacs instance
running under a graphical session should prefer pinentry-emacs by
default over the standard graphical prompting?
what should users expect?
Regards,
--dkg
signature.asc
Description: PGP signature
