Page MenuHome GnuPG

use FD passing instead of /tmp/emacs$UID/pinentry
Closed, WontfixPublic

Description

The Emacs fallback mode of Pinentry currently uses a Unix domain
socket (/tmp/emacs$UID/pinentry) to communicate with Emacs. However,
given that the caller of gpg is supposedly the same process as the
Emacs running pinentry.el, we could use FD passing instead:

 +--------------------------+
 | emacs            	     |
 |   create bidi pipe       |
 +-------+----------^-------+
	  |	     |
  1. inherit fd (fork) | | | +-------v-----+ | | gpg | | +-------+-----+ |
	  |	     |
   2. fd passing     | 4. communicate through the fd
	  | 	     |
  +-------v-----+    |
  | gpg-agent   |    |
  +-------+-----+    |
	  |	     |
  1. inherit fd (fork) |
	  |	     |
  +-------v----------+-------+
  | pinentry                 |
  +--------------------------+

This requires changes to Emacs, GnuPG, and Pinentry, but it would
reduce the attack surface a bit and bring a better support for
multiple Emacs instances.

Details

Version
0.9.7

Event Timeline

ueno set Version to 0.9.7.
ueno added a subscriber: ueno.

Does this mean that pinentry-emacs will only work when an emacs instance calls
gpg? Does pinentry-emacs need to support the case that a program other than
emacs calls gpg?

Does this mean that pinentry-emacs will only work when an emacs instance calls

gpg?

Yes, it is the intention of this proposal.

Does pinentry-emacs need to support the case that a program other than

emacs calls gpg?

I don't think it is worth being supported. It would be rather confusing if a
GUI program internally using gpg asked passphrases from Emacs window.

I think this is reasonable. If you want to implement it, I'll review the
patches. Thanks.

I have done some experiment with it, and it works (though I had
to add ASSUAN_*_FDPASSING flags to a couple of places in gnupg).
However, I think I still need some more opinions to make it a
reviewable state.

First, to make all the things work, gpg would need a new
option (or an envvar?) to tell the FD number. Naively, it could
be named as --emacs-fd, which only works if INSIDE_EMACS is set.
However, it might be too specific, and sounds over-engineering to
me.

Instead, we could add a more generic option, say, --pinentry-fd.
With that option, any pinentry could talk to the caller through
the FD with the Assuan protocol. For security, the effect of the
option shall be restricted only when --pinentry-mode=loopback is
set and working.

In that case, it's tempting to make gpg-agent directly talk to
the FD, instead of spawning pinentry. However, it cannot take
advantage of pinentry's libsecret support and the diversion to
other pinentries (GTK+, ...). Also, it might be a similar
concept of --pinentry-program, which I proposed and was rejected.

What do you think?

Actually, I'm not sure about the current recommendation on the
custom passphrase input options. Given the recent bug fixes,
could --pinentry-mode=loopback be publicly promoted? If so,
I'm happy to withdraw this (and perhaps INSIDE_EMACS stuff) and
add a hack to use --pinentry-mode=loopback.

marcus claimed this task.
marcus added a subscriber: marcus.

Loopback is now officially supported, so I am closing this.