Question: how to setup with pinentry-curses?

[nikolay-turpitko]

Cool project overall. But how can I deal with pinentry?
When I use plugin right after I issued some commands to gopass and credentials are still cached, it works OK. But after timeout it cannot connect to gopass. Obviously, gopass want me to re-enter passphrase via pinentry (which is curses-based in my setup), and cannot open it. How can I modify wrapper script to open terminal window with pinentry? Or may be some suggestion how to better deal with it?

BTW, is it at all possible to request passphrase in plugin's UI when necessary and pass it to gopass via CLI or jsonapi protocol? If it's currently not implemented, but is possible, what should be done to implement it?

[nikolay-turpitko]

OK, I sorted it out. There are couple of options.

First, there is configuration file ~/.gnupg/gpg-agent.conf, where desired pinentry program can be configured. Like pinentry-program /usr/local/bin/pinentry-mac for Mac OS, or pinentry-program /usr/local/bin/pinentry-qt for Linux (pinentry package should be installed via package manager additionally to gpg). This way works for me on Mac.

Next, it's possible to choose pinentry program dynamically. For example, with wrapper like this: https://github.com/acobaugh/dotfiles/blob/2e97f86ba90e2d18b1cf2b3c4b40455ce0f8289b/bin/my-pinentry, in this case environment variable should be exported in ~/.config/gopass/gopass_wrapper.sh like export PINENTRY_USER_DATA=gtk. For some reason I was not able to make it work stably on my Debian machine. Probably, because of firejail profile for chromium, which I use. Or because of some issues with path. It's difficult to experiment with this, because of several moving parts, which get cached somewhere. I had to reboot for clear results, even re-login wasn't help. I was able to make it work once, but changed something and it broke after reboot, and I was not able to reproduce correct settings. Probably, I should use absolute path to wrapper script, but it's not quite suits me.

Last option, which I like more, is to pass --pinentry-program /usr/bin/pinentry-x11 to gpg-agent within ~/.config/gopass/gopass_wrapper.sh. It works for me on Debian and I currently test it to see how stable it is.

UPDATE: unfortunately, in both cases (pinentry wrapper and gpg-agent argument) whatever chosen first is cached somewhere. If, for example, I use pinentry-ncurses first, then gpg-agent stick to it, and pinentry not appear on click in gopassbridge. I tried kill gpg-agent, pinentry, restart agent different ways, but nothing helped except reboot. Finally, I gave up and decided to use first option - configure x11 version for every program, requiring it.

[martinhoefling]

Thx for your hints. I am also not aware of a solution to dynamically configure pinentry toosl

[adrianlzt]

I have solved this issue using env vars.

➜ cat ~/.config/gopass/gopass_wrapper.sh | grep gopass
PINENTRY_USER_DATA=qt /usr/bin/gopass jsonapi listen

➜ cat ~/.gnupg/gpg-agent.conf | grep env
pinentry-program /home/adrian/bin/pinentry-env

➜ cat pinentry-env
#!/bin/bash
# choose pinentry depending on PINENTRY_USER_DATA
# requires pinentry-curses and pinentry-gtk2
# this *only works* with gpg 2
# see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802020

case $PINENTRY_USER_DATA in
gtk)
  exec /usr/bin/pinentry-gtk-2 "$@"
  ;;
gnome3)
  exec /usr/bin/pinentry-gnome3 "$@"
  ;;
qt)
  exec /usr/bin/pinentry-qt "$@"
  ;;
curses)
  exec /usr/bin/pinentry-curses "$@"
  ;;
*)
  exec /usr/bin/pinentry-tty "$@"
esac

[kristianmitk]

@adrianlzt simple and neat, thanks!

Following are minor adjustments for OSX users (assuming brew as package manager and pinentry-mac in PATH):

• replace qt with mac
• prefix pinentry-* with /usr/local/bin/ - e.g. /usr/local/bin/pinentry-curses

---

@martinhoefling what about adding the env var approach to the README?