5

When using gpg-agent with git tag -u, I'm getting the following error immediately:

gpg: cancelled by user
gpg: skipped "[email protected]": bad passphrase
gpg: signing failed: bad passphrase
error: gpg failed to sign the data
error: unable to sign the tag

gpg-agent.conf:

pinentry-program /usr/bin/pinentry-curses

When I unlock the key first (via a gpg -e -s test.txt), then the git tag -u command picks up the key and signs the tag as expected.

This is on ubuntu 13.10, using i3 wm. I'd be suspicious that gnome-keyring is somehow hampering...something, but on an raspberry pi, running archlinux-arm, it works the same way, but with a slightly different issue -- After running the git tag -u command, it asks for a password to unlock, but no pinentry or prompt appears. After a time (about 30 seconds), it fails with the following:

gpg: problem with the agent: Line passed to IPC too long
gpg: skipped "[email protected]": Operation cancelled
gpg: signing failed: Operation cancelled
error: gpg failed to sign the data
error: unable to sign the tag

Again, once I unlock the key with a straight gpg -s to an arbitrary file to cache the credentials in gpg-agent, the tag is signed without issue.

My assumption is that something is weird with my useage of pinentry-curses. I have already updated /usr/bin/pinentry to point to /usr/bin/pinentry-curses, but the problem persists.

What am I doing wrong, and how do I get git to play nice with gpg/pinentry?

  • ubuntu gpg version: 1.4.14
  • archlinux-arm gpg version: gnupg-2.0.22-1

EDIT: running zsh. Here is the relevant bit sourced for the gpg agent:

if [ $EUID -ne 0 ] ; then
    envfile="$HOME/.gnupg/gpg-agent.env"
    if [[ -e "$envfile" ]] && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
        eval "$(cat "$envfile")"
    else
        eval "$(gpg-agent --daemon --write-env-file "$envfile")"
    fi
    export GPG_AGENT_INFO  # the env file does not contain the export statement
fi

when I follow $(tty) (eg: /dev/pts/16) the ownsership is already user:tty.

Improve this question

2 Answers 2

Reset to default
4

You will also need to export the GPG_TTY variable every time when you start a new TTY (could also be done from bash/zsh rc files):

export GPG_TTY=$(tty)
Improve this answer
0

Problems with the Pinentry ncurses dialog are related to the ownership of the TTY pinentry tries to use (if you initially login as a user & then su for example).

Put the following script into /etc/profile.d/gpg-agent.sh to fix it ( you may want to omit the outer if on a multi user system or change the condition to != ) :

if [ "$(id -un)" = "root" ] ; then
    envfile="$HOME/.gnupg/gpg-agent.env"
    if [[ -e "$envfile" ]] && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
        eval "$(cat "$envfile")"
    else
        eval "$(gpg-agent --daemon --enable-ssh-support --write-env-file "$envfile")"
    fi

    export GPG_AGENT_INFO    # the env file does not contain the export statement
    export SSH_AUTH_SOCK     # enable gpg-agent for ssh

    GPG_TTY=$(tty)
    chown $USER:tty $GPG_TTY # make pinentry-ncurses work
fi
Improve this answer
2
  • Thanks for the pointers -- however, I've already got something like that in my .zshrc, all except for the chown, but it's still no good. The permissions in /dev/pts are already set correctly. Adding the chown did not resolve the issue. The only difference between your snippet and mine is that I'm not enabling my gpg agent for ssh. I couldn't see that as making a difference, would it?
    – Jeff Wong
    Commented Apr 23, 2014 at 21:29
  • I was having similar problem with Duply / Duplicity signing backups - the solution was from the GnuPG in Automated Environments FAQ. On Alpine Linux I still need the chown for pinentry-curses to work correctly (so you may do on Arch too) - Debian does not need chown on the tty.
    – Stuart Cardall
    Commented Oct 1, 2014 at 1:00

You must log in to answer this question.

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