☰

Git-Tag mit GPG-Agent und Pinentry-Curses

tag-icon • tag-icon git gnupg
Git-Tag mit GPG-Agent und Pinentry-Curses

Wenn ich gpg-agent mit git tag -u verwende, erhalte ich sofort die folgende Fehlermeldung:

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

Wenn ich den Schlüssel zuerst entsperre (über einen gpg -e -s test.txt), git tag -uholt der Befehl den Schlüssel ab und signiert das Etikett wie erwartet.

Dies ist auf Ubuntu 13.10, mit i3 wm. Ich hätte den Verdacht, dass Gnome-Keyring irgendwie behindert... etwas, aber auf einem Raspberry Pi, auf dem Archlinux-Arm läuft, funktioniert es genauso, aber mit einem etwas anderen Problem – Nach dem Ausführen des git tag -uBefehls wird nach einem Passwort zum Entsperren gefragt, aber es erscheint keine PIN-Eingabe oder Eingabeaufforderung. Nach einiger Zeit (ungefähr 30 Sekunden) schlägt es mit folgendem fehl:

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

Wenn ich den Schlüssel erneut entsperre, indem ich direkt gpg -sauf eine beliebige Datei zugreife, um die Anmeldeinformationen im GPG-Agenten zwischenzuspeichern, wird das Tag ohne Probleme signiert.

Ich gehe davon aus, dass bei meiner Verwendung von pinentry-curses etwas nicht stimmt. Ich habe /usr/bin/pinentry bereits aktualisiert, sodass es auf /usr/bin/pinentry-curses verweist, aber das Problem besteht weiterhin.

Was mache ich falsch und wie bringe ich Git dazu, gut mit GPG/Pinentry zu funktionieren?

  • Ubuntu GPG-Version: 1.4.14
  • archlinux-arm gpg-Version: gnupg-2.0.22-1

BEARBEITEN: zsh wird ausgeführt. Hier ist die relevante Bit-Quelle für den GPG-Agenten:

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

Wenn ich $(tty) folge (zB: /dev/pts/16), ist der Eigentümer bereits user:tty.

Antwort1

Sie müssen außerdem dieGPG_TTYVariable jedes Mal, wenn Sie ein neues TTY starten (kann auch über Bash/Zsh-RC-Dateien erfolgen):

export GPG_TTY=$(tty)

Antwort2

Probleme mit dem Pinentry-ncurses-Dialog hängen mit dem Besitz des TTY zusammen, das Pinentry zu verwenden versucht (wenn Sie sich zunächst als Benutzer anmelden und dann beispielsweise su verwenden).

Fügen Sie das folgende Skript in/etc/profile.d/gpg-agent.shifum das Problem zu beheben ( auf einem Mehrbenutzersystem können Sie das Äußere weglassen oder die Bedingung in != ändern):

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

verwandte Informationen