2

I'm having some trouble getting gpg (actually pass which uses gpg in the background) to work inside of tmux and a Yubikey Neo. When attempting to decrypt a file or sign something using gpg I get the following:

$ gpg -d test.gpg            
gpg: sending command `SCD PKDECRYPT' to agent failed: ec=5.99
gpg: public key decryption failed: general error
gpg: decryption failed: secret key not available

This is only inside of tmux, if I attempt to run the same command in a normal zsh session directly in gnome-terminal it just works:

gpg -d test.gpg 
helloworld

pinentry will pop up, ask me for the PIN to unlock the Yubikey and proceed to decrypt the file.

I think I narrowed the problem down to pinentry not being able to spawn. Setting the log level of the gpg-agent I get the following: 

gpg-agent[906]: DBG: chan_6 <- INQUIRE NEEDPIN ||Please enter the PIN
gpg-agent[906]: starting a new PIN Entry
gpg-agent[906]: DBG: chan_7 <- OK Pleased to meet you, process 906
gpg-agent[906]: DBG: connection to PIN entry established
... options removed ...
gpg-agent[906]: DBG: chan_7 -> GETINFO pid
gpg-agent[906]: DBG: chan_7 <- D 13381
gpg-agent[906]: DBG: chan_7 <- OK
gpg-agent[906]: DBG: chan_7 -> SETKEYINFO --clear
gpg-agent[906]: DBG: chan_7 <- OK
gpg-agent[906]: DBG: chan_7 -> SETDESC Please enter the PIN
gpg-agent[906]: DBG: chan_7 <- OK
gpg-agent[906]: DBG: chan_7 -> SETPROMPT PIN
gpg-agent[906]: DBG: chan_7 <- OK
gpg-agent[906]: DBG: chan_7 -> [[Confidential data not shown]]
gpg-agent[906]: DBG: chan_7 <- [[Confidential data not shown]]
gpg-agent[906]: DBG: error calling pinentry: Operation cancelled <Pinentry>
gpg-agent[906]: DBG: chan_7 -> BYE
gpg-agent[906]: DBG: chan_6 -> CAN
gpg-agent[906]: DBG: chan_6 <- ERR 100663573 IPC call has been cancelled <SCD>
gpg-agent[906]: DBG: chan_5 -> ERR 83886179 Operation cancelled <Pinentry>

Nothing suspicious jumps out at me, except a few OPTION statements that apparently aren't handled by pinentry but I get the same when calling from gnome-terminal.

Setting the $DISPLAY variable also doesn't help, the error is identical.

Am I missing something? Is there some other variable I need to set? And why doesn't this fall back to pinentry-ncurses if it can't open a graphical one?

Improve this question
6
  • Does gpg-connect-agent UPDATESTARTUPTTY /bye help?
    – Hauke Laging
    Oct 7, 2017 at 19:38
  • Sadly no change, it replies with OK but subsequent calls to gpg will error out like previously. I also tried setting the tty manually with export GPG_TTY="$(tty)" without any change.
    – cdecker
    Oct 8, 2017 at 13:26
  • You could trace the running gpg-agent with strace -f -o dump.strace -p $PID once for both terminals each and then have a look at the differences.
    – Hauke Laging
    Oct 8, 2017 at 13:36
  • That's a really good tip, thanks Hauke. I was able to trace both processes side by side and they differ when attempting to talk to dbus. The tmux gpg fails to connect for some reason. If I set the DBUS_SESSION_BUS_ADDRESS variable in tmuxas well it suddenly works.
    – cdecker
    Oct 8, 2017 at 13:57
  • Ok, so this seems to be fixed by adding set-option -g update-environment 'DBUS_SESSION_BUS_ADDRESS' to my .tmux.conf. So in the end it was just a stale dbus environment variable... Thanks for the help Hauke, if you'd like to write a short response I'll gladly accept it ^^
    – cdecker
    Oct 8, 2017 at 14:07

1 Answer 1

Reset to default
7

The problem was that (for some reason) gpg tries to use dbus but within tmux the environment variable DBUS_SESSION_BUS_ADDRESS was outdated.

This can be fixed with

set-option -g update-environment 'DBUS_SESSION_BUS_ADDRESS'

in .tmux.conf.

Improve this answer
1
  • I'm not sure why, but this didn't work for me by just executing :set-option ... from my existing tmux session -- I had to add this to my .tmux.conf file and restart tmux (like you say)
    – Nathan Wallace
    Jun 18, 2019 at 14:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .