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

Daiki Ueno ueno at gnu.org
Sun Feb 12 19:47:08 UTC 2017


Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> /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.

In which degree do you argue against that?  emacs --daemon and
emacsclient traditionally use a similar path (/tmp/emacs$UID/server) and
the file permissions are properly set.  Do you think those should be
fixed or this pinentry use-case is special for some reason?

>> 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?

Not really.  It has been a common use-case for a decade:
https://www.emacswiki.org/emacs/EasyPG#toc4

Until the majority of distributions adopted GnuPG 2, the suggestion was
to install gpg1 along with gpg2 (as EasyPG prefers gpg1).  However, it
no longer works because some distributions do not ship gpg1 anymore.

> 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.

It is not activated unless the user explicitly enables it in
~/.gnupg/gpg-agent.conf, as I wrote before.

Regards,
-- 
Daiki Ueno



More information about the pkg-gnupg-maint mailing list