gpg konnte die schwerwiegenden Daten nicht signieren: Commit-Objekt konnte nicht geschrieben werden [Git 2.10.0]

Ich habe einige Artikel über die hübschen Attribute in Git 2.10 Release Note verfolgt. Durchlaufen, wodurch das Git auf 2.10.0 aktualisiert und Änderungen an Global vorgenommen wurden, .gitconfigdie sich wie folgt ergaben :

[filter "lfs"]
    clean = git-lfs clean %f
    smudge = git-lfs smudge %f
    required = true
[user]
    name = xyz
    email = abc.def@gmail.com
    signingkey = AAAAAAA
[core]
    excludesfile = /Users/xyz/.gitignore_global
    editor = 'subl' --wait
[difftool "sourcetree"]
    cmd = opendiff \"$LOCAL\" \"$REMOTE\"
    path = 
[mergetool "sourcetree"]
    cmd = /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"
    trustExitCode = true
[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
[color "diff"]
    old = red strike
    new = green italic

Aber jetzt, wo ich versuche, meine Commits mit zu unterschreiben

git commit -a -S -m "message"

Ich sehe folgenden Fehler:

Sie benötigen eine Passphrase, um den geheimen Schlüssel für zu entsperren

Benutzer: "XYZ (digital signiert)"

2048-Bit-RSA-Schlüssel, ID AAAAAAAA, erstellt am 01.07.2016

Fehler: GPG konnte die Daten nicht signieren. Schwerwiegend: Commit-Objekt konnte nicht geschrieben werden

Hinweis - Ich kann weiterhin Änderungen mit festschreibengit commit -a -m "message"

Gibt es eine Möglichkeit, dasselbe zu überwinden? Oder eine Änderung in gpgKonfigurationen, um mit der Aktualisierung von Git auszukommen?

Update 1

Suchen Sie nach einer Möglichkeit, Commits in Git mit einem GPG-Schlüssel automatisch zu signieren? . Ich habe den Schlüssel bereits mit konfiguriert

git config --global user.signingkey ED5CDE14(with my key) 
git config --global commit.gpgsign true

und ganz offensichtlich trotzdem den gleichen Fehler bekommen.

Ich bin auf dieses Problem mit OSX gestoßen.

Ursprüngliche Antwort:

Es scheint, als ob ein GPG-Update (von Brew) in den Speicherort von gpgto geändert gpg1wurde. Sie können die Binärdatei ändern, in der Git das GPG nachschlägt:

git config --global gpg.program gpg1

Wenn Sie kein gpg1 haben: brew install gpg1 .

Aktualisierte Antwort:

Es sieht so aus, als ob gpg1 veraltet ist / "sanft aus der Nutzung gedrängt" wird , daher sollten Sie wahrscheinlich tatsächlich auf gpg2 aktualisieren. Leider erfordert dies einige weitere Schritte / einige Zeit:

brew upgrade gnupg  # This has a make step which takes a while
brew link --overwrite gnupg
brew install pinentry-mac
echo "pinentry-program /usr/local/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
killall gpg-agent

Der erste Teil installiert gpg2, und letzterer ist ein Hack, der erforderlich ist, um es zu verwenden . Informationen zur Fehlerbehebung finden Sie in dieser Antwort (obwohl es sich um Linux handelt, das nicht gebraut wird). Sie schlägt einen guten Test vor:

echo "test" | gpg --clearsign  # on linux it's gpg2 but brew stays as gpg

Wenn dieser Test erfolgreich ist (kein Fehler / keine Ausgabe enthält die PGP-Signatur), haben Sie erfolgreich auf die neueste GPG-Version aktualisiert.

Sie sollten jetzt wieder in der Lage sein, Git Signing zu verwenden!
Es ist erwähnenswert, dass Sie Folgendes benötigen:

git config --global gpg.program gpg  # perhaps you had this already? On linux maybe gpg2
git config --global commit.gpgsign true  # if you want to sign every commit

Hinweis: Nachdem Sie ein signiertes Commit ausgeführt haben, können Sie überprüfen, ob es signiert ist mit:

git log --show-signature -1

Dies beinhaltet GPG-Informationen für das letzte Commit.

Wenn gnupg2 und gpg-agent 2.x verwendet werden, müssen Sie die Umgebungsvariable festlegen GPG_TTY.

export GPG_TTY=$(tty)

Informationen zu häufigen Problemen finden Sie in der GPG-Dokumentation .

Wenn alles fehlschlägt, GIT_TRACE=1versuchen Sie mit, zu sehen, was Git tatsächlich tut:

$ GIT_TRACE=1 git commit -m "Add page that always requires a logged-in user"
20:52:58.902766 git.c:328               trace: built-in: git 'commit' '-vvv' '-m' 'Add page that always requires a logged-in user'
20:52:58.918467 run-command.c:626       trace: run_command: 'gpg' '--status-fd=2' '-bsau' '23810377252EF4C2'
error: gpg failed to sign the data
fatal: failed to write commit object

Führen Sie nun den fehlgeschlagenen Befehl manuell aus:

$ gpg -bsau 23810377252EF4C2
gpg: skipped "23810377252EF4C2": Unusable secret key
gpg: signing failed: Unusable secret key

Es stellte sich heraus, mein Schlüssel war abgelaufen, gitwar nicht schuld.

Ich habe es durch dieses kurze und einfache Rezept getan :

Auto-Sign-Commits unter macOS (global und mit verschiedenen IDEs):

Holen Sie sich Ihre signingkeyauf diese Weise .

brew install gnupg gnupg2 pinentry-mac
git config --global user.signingkey <YOUR_SIGNING_KEY>
git config --global commit.gpgsign true
git config --global gpg.program gpg

Fügen Sie Folgendes in die gpg.confDatei ein (bearbeiten Sie die Datei mit dem nano ~/.gnupg/gpg.confBefehl):

no-tty

Fügen Sie Folgendes in die gpg-agent.confDatei ein (bearbeiten Sie die Datei mit dem nano ~/.gnupg/gpg-agent.confBefehl):

pinentry-program /usr/local/bin/pinentry-mac

Update :

Möglicherweise müssen Sie den killall gpg-agentBefehl nach dem Bearbeiten der Konfigurationsdatei gpg.confgemäß den Kommentaren ausführen . Wie der selbsterklärende Befehl sagt, beendet dieser Befehl den GPG-Agenten (Gnu Privacy Guard).

Kann helfen, Prozesse zu beenden, gpg-agentdie möglicherweise bei alten Daten hängen bleiben. Also neu gpg-agentgestartet würde nach Passwort fragen.

Folgen Sie der folgenden URL, um das signierte Commit https://help.github.com/de/articles/telling-git-about-your-signing-key einzurichten

Wenn immer noch gpg nicht signiert werden konnte, konnte das Commit-Objekt nicht geschrieben werden

Dies ist kein Problem mit Git, dies ist mit GPG folgen Sie den folgenden Schritten

1.gpg --version

2. echo "test" | gpg --clearsign

wenn es zeigt:

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

3. dann benutze export GPG_TTY=$(tty)

4. Versuchen Sie dann erneut, echo "test" | gpg --clearsign die PGP-Signatur zu erhalten.

5. git config -l | grep gpg

gpg.program = gpg commit.gpgsign = true

6. anwenden git commit -S -m "commitMsz"

Versuchen Sie Folgendes für alle, die auf MacOS- Computern mit diesem Problem konfrontiert sind :

1. brew uninstall gpg
2. brew install gpg2
3. brew install pinentry-mac (wenn benötigt)
4. gpg --full-generate-key Erstellen Sie einen Schlüssel mithilfe eines Algorithmus.
5. Erhalten Sie den generierten Schlüssel, indem Sie Folgendes ausführen: gpg --list-keys
6. Stellen Sie hier den Schlüssel ein git config --global user.signingkey <Key from your list>
7. git config --global gpg.program /usr/local/bin/gpg
8. git config --global commit.gpgsign true
9. Wenn Sie Ihren Schlüssel in GitHub exportieren möchten, dann: gpg --armor --export <key> und fügen Sie diesen Schlüssel unter GPG-Schlüsseln zu GitHub hinzu: https://github.com/settings/keys (mit START- und END-Zeile)

Wenn das Problem weiterhin besteht:

test -r ~/.bash_profile && echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile

echo 'export GPG_TTY=$(tty)' >> ~/.profile

Wenn das Problem weiterhin besteht:

Installieren Sie https://gpgtools.org und unterzeichnen Sie die Taste , die Sie durch Drücken verwendet Zeichen in der Menüleiste: Key -> Zeichen

Wenn das Problem weiterhin besteht:

Gehe zu: Ihre globale .gitconfigDatei , die in meinem Fall ist: /Users/gent/.gitconfig Und ändern Sie die .gitconfig Datei (bitte stellen Sie sicher , E - Mail und Namen sind gleich mit der einen , die Sie erstellt haben , während der Schlüssel zu erzeugen) :

[user]
	email = gent@youremail.com
	name = Gent
	signingkey = <YOURKEY>
[gpg]
	program = /usr/local/bin/gpg
[commit]
	gpsign = true
	gpgsign = true
[filter "lfs"]
	process = git-lfs filter-process
	required = true
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
[credential]
	helper = osxkeychain

Meine zwei Cent hier:

Wenn Sie einen Schlüssel für gpg-agent erstellen und hinzufügen, definieren Sie einen so genannten Namen passphrase. Nun, da passphraseirgendwann abläuft, undgpg Sie es erneut eingeben müssen, um Ihren Schlüssel zu entsperren, damit Sie wieder mit dem Signieren beginnen können.

Wenn Sie ein anderes Programm verwenden, mit dem eine Schnittstelle besteht gpg, wird gpgdie Aufforderung zur Eingabe Ihrer Passphrase nicht angezeigt (im Grunde gpg-agentkann der Eingabedialog in der Dämonisierung möglicherweise nicht angezeigt werdenstdin ).

Eine der Lösungen besteht darin gpg --sign a_file.txt, die Passphrase einzugeben, die Sie beim Erstellen Ihres Schlüssels eingegeben haben, und dann sollte alles in Ordnung sein ( gpg-agentsollte automatisch signieren).

Siehe diese Antwort erfahren Sie, wie Sie längere Zeitüberschreitungen für Ihre Passphrase festlegen, damit Sie dies nicht immer tun müssen.

Oder Sie können die Passphrase mit vollständig entfernen ssh-keygen -p

Bearbeiten: Machen Sie eine man gpg-agent, um einige Dinge darüber zu lesen, wie das oben Genannte automatisch geschehen soll, und fügen Sie die Zeilen hinzu:

GPG_TTY=$(tty)
export GPG_TTY

auf Ihrer .bashrc, wenn Sie bash verwenden (dies ist die richtige Antwort, aber ich behalte auch meinen Gedankengang oben bei)

Update Okt. 2016: In Ausgabe 871 wurde erwähnt, dass das Signieren in Git 2.9.3 nicht mehr funktioniert.

Git für Windows 2.10.1, das vor zwei Tagen (4. Oktober 2016) veröffentlicht wurde, hat die interaktive GPG-Signatur von Commits und Tags behoben.

Die jüngste Änderung des gpg-Zeichens in git (die unter Linux kein Problem darstellt) stellt ein Problem in der Art und Weise dar, in der Nicht-MSYS2-git unter Windows mit MSYS2-gpg interagiert.

Ursprüngliche Antwort:

Beim Lesen von " 7.4 Git Tools - Signieren Ihrer Arbeit " gehe ich davon aus, dass Sie Ihre " user.signingkey" Konfiguration festgelegt haben.

Das letzte große Refactoring (vor Git 2.10) um gpg war in commit 2f47eae2a , hier wurde diese Fehlermeldung verschobengpg-interface.c

Ein Protokoll in dieser Datei zeigt die letzte Änderung in commit af2b21e (Git 2.10).

gpg2 verwendet standardmäßig bereits das Langformat, aber die meisten Distributionen scheinen aus Kompatibilitätsgründen immer noch "gpg" als ältere 1.x-Version zu haben. Und ältere Versionen von gpg zeigen nur die 32-Bit-Kurz-ID an, was ziemlich unsicher ist.

Dies ist für die Überprüfung selbst eigentlich nicht wichtig : Wenn die Überprüfung erfolgreich ist, ist die pgp-Signatur gut.
Wenn Sie den Schlüssel jedoch noch nicht haben und ihn abrufen möchten oder genau prüfen möchten, welcher Schlüssel zur Überprüfung verwendet wurde, und ihn überprüfen möchten, sollten Sie den Schlüssel genauer angeben.

Überprüfen Sie also, wie Sie Ihre angegeben haben user.signingkey Konfiguration angegeben haben und welche Version von gpg Sie verwenden (gpg1 oder gpg2), um festzustellen, ob diese Auswirkungen auf die Fehlermeldung haben.

Es gibt auch ein Commit 0581b54, das die Bedingung für die gpg failed to sign the dataFehlermeldung ändert (in Ergänzung zum Commit 0d2b664 ):

Wir lesen derzeit überhaupt nicht von stderr. Allerdings werden wir in einem zukünftigen Patch wollen, so ist auch dies bereitet uns dort (und in diesem Fall gpg tut Schreib vor allem der Eingang zu lesen, obwohl wieder, es ist unwahrscheinlich , dass ein Schlüssel uid ein Rohrpuffer füllen wird).

Commit 4322353 zeigt, dass gpg jetzt eine temporäre Datei verwendet, sodass möglicherweise die richtigen Probleme auftreten.

Lassen Sie uns ein tempfile-Objekt verwenden, das die schwierigen Fälle für uns behandelt, und den fehlenden Bereinigungsaufruf hinzufügen.

Die Git-Spur war für meine Situation sehr aufschlussreich ...

   GIT_TRACE=1 git commit -m "a commit message"

   13:45:39.940081 git.c:344               trace: built-in: git commit -m 'a commit message'
   13:45:39.977999 run-command.c:640       trace: run_command: gpg --status-fd=2 -bsau 'full name <your-email@domain.com>'
   error: gpg failed to sign the data
   fatal: failed to write commit object

Ich musste einen Anfangsschlüssel für das Format generieren git, gegen das geprüft wurde. Am besten kopieren Sie den übergebenen Wert-bsau wie er ist in die Protokolle und unten zu verwenden.

So wird es,

   gpg --quick-generate-key "full name <your-email@domain.com>"

Dann hat es funktioniert.

Ich hoffe, das hilft.

Mit Cygwin habe ich kürzlich zu gewechselt gpg2. Dann hatte ich das gleiche Problem beim Signieren mit git nach dem Einstellen git config gpg.program gpg2.

Versuchen Sie echo "test" | gpg2 --clearsignzu sehen, ob gpg2 funktioniert. Ich fand es die einfachste Lösung, nur zu setzen git config gpg.program gpg, weil das funktioniert. Auf diese Weise erhalten Sie jedoch auch einen besseren Fehler - z. B. dass Sie pinentry installieren müssen.

Unter OS X, gnupg2wenn ich via Brew benutze, musste ich nur den GPG-Agenten töten , passiert manchmal:

pkill -9 gpg-agent

Und setzen Sie die envVariable bei Bedarf:

export GPG_TTY=$(tty)

Siehe auch Allgemeine GPG-Probleme und diese Antwort auch hier.

Ich habe ähnliche Antworten gesehen, aber nichts genaues, was für mich funktioniert hat. Unter Linux musste ich meine beenden und neu starten gpg-agentmit:

$ pkill gpg-agent
$ gpg-agent --daemon
$ git commit ...

Das hat den Trick für mich getan. Es sieht so aus, als müssten Sie auch user.signingkeyIhren privaten Schlüssel festgelegt haben, wie in einigen anderen Kommentaren angegeben.

$ git config --global user.signingkey [your_key_hash]

Könnte ein hängender GPG-Agent sein.

Versuchen Sie es gpgconf --kill gpg-agent wie hier beschrieben

Ich habe diesen Fehler unter Ubuntu 18.04 erhalten und es stellte sich heraus, dass mein Schlüssel abgelaufen war .

Um dies zu sehen, habe ich dies ausgeführt und es wurde bestätigt, dass meine Schlüssel abgelaufen sind:

gpg --list-keys

Um dies zu korrigieren, habe ich ausgeführt (unter Verwendung der im vorherigen Befehl angezeigten ID):

gpg --edit-key <ID>

Von dort verlängerte ich den Ablauf key 0und key 1folgenden diese Anleitung , die eingekocht , um die Eingabe key 0dann expireund folgen Sie die Anweisungen. Dann wiederholen fürkey 1 .

Um dies zu testen, lief ich danach:

echo test | gpg --clearsign

Und vor dem Fix schlug es mit dem Fehler fehl:

gpg: kein geheimer Standardschlüssel: kein geheimer Schlüssel
gpg: [stdin]: Löschzeichen fehlgeschlagen: kein geheimer Schlüssel

Aber nach dem Fix hat derselbe Befehl die Nachricht erfolgreich signiert, sodass ich wusste, dass die Dinge wieder funktionieren!

Ich bin auf das gleiche Problem gestoßen. Ich freue mich, berichten zu können, dass das Problem nicht bei, git 2.10.0sondern bei liegtgnupg 1.4.21 .

Das vorübergehende Herabstufen von gnupg auf 1.4.20 hat das Problem für mich behoben.

Wenn Sie Homebrew verwenden und Ihre Pakete wie ich aktualisiert haben, können Sie wahrscheinlich einfach ausführen brew switch gnupg 1.4.20, um zurückzukehren.

Stellen Sie sicher, dass Ihre E-Mail richtig eingestellt ist.

git config --global user.email "user@example.com"

Wenn sich die der UID Ihres GPG-Schlüssels zugeordnete E-Mail von der in git verwendeten E-Mail unterscheidet, müssen Sie Ihrem Schlüssel eine andere Benutzer-ID hinzufügen ODER einen Schlüssel verwenden, der genau mit der E-Mail übereinstimmt.

Sie können eine weitere UID hinzufügen, indem Sie Folgendes verwenden:

$ gpg --edit-key

Siehe für mo /superuser/293184/one-gnupg-pgp-key-pair-two-emails

Ich muss versehentlich gpg irgendwie aktualisiert haben, weil ich dies bekam, nachdem ich versucht hatte zu testen, ob gpg funktioniert:

gpg: WARNING: server 'gpg-agent' is older than us (2.1.21 < 2.2.10)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.

Laufen hat gpgconf --kill alles für mich behoben.

Hoffe das hilft jemandem.

Ich hatte ein ähnliches Problem mit den neuesten Git-Quellen (2.12.2), die zusammen mit den neuesten Quellen aller Abhängigkeiten (Zlib, Bzip, cURL, PCRE, ReadLine, IDN2, iConv, Unistring usw.) erstellt wurden.

Es stellte sich heraus, libreadlinedass GnuPG Probleme gab:

$ gpg --version
gpg: symbol lookup error: /usr/local/lib/libreadline.so.7: undefined symbol: UP

Und natürlich versuchen, nützliche Informationen von Git mit zu bekommen -vvv fehlgeschlagen, daher war der Fehler ein Rätsel.

Befolgen Sie die Anweisungen unter Fehler beim Aktualisieren oder Verwenden des Paketmanagers - gpg-Fehler, um den PGP-Fehler aufgrund von ReadLine zu beheben :

Im Terminal:

ls /usr/local/lib

Es gab eine Reihe von Readline-Bibliotheken (libreadline.so.BLAH-BLAH), also i:

su
mkdir temp
mv /usr/local/lib/libreadline* temp
ldconfig

Die obigen Antworten sind großartig, aber sie haben bei mir nicht funktioniert. Was mein Problem löste, war das Exportieren sowohl des öffentlichen als auch des geheimen Schlüssels.

Listen Sie die Schlüssel von der Maschine auf, von der wir exportieren

$ gpg --list-keys
/home/user/.gnupg/pubring.gpg
--------------------------------
pub 1024D/ABCDFE01 2008-04-13
uid firstname lastname (description) <email@example.com>
sub 2048g/DEFABC01 2008-04-13

Exportieren Sie die Schlüssel

$ gpg --output mygpgkey_pub.gpg --armor --export ABCDFE01
$ gpg --output mygpgkey_sec.gpg --armor --export-secret-key ABCDFE01

Gehen Sie zur Maschine, in die wir importieren, und importieren Sie sie

$ gpg --import ~/mygpgkey_pub.gpg
$ gpg --allow-secret-key-import --import ~/mygpgkey_sec.gpg

Bingo Bongo, du bist fertig!

Referenz: https://www.debuntu.org/how-to-importexport-gpg-key-pair/

ps. Meine Schlüssel wurden ursprünglich unter Bootcamp Windows 7 erstellt und ich exportierte sie auf meinen Mac Air (dieselbe physische Maschine, virtuell unterschiedlich).

Ich bin auf Ubuntu 18.04 und habe den gleichen Fehler bekommen, war auch wochenlang besorgt. Endlich wurde klar, dass gpg2 auf nichts zeigt. Also einfach rennen

git config --global gpg.program gpg

Und Tada, es funktioniert wie Charme.

Ihre Commits haben jetzt ein verifiziertes Tag mit ihnen.

Ich bin auf diesen Fehler nicht aufgrund eines Konfigurationsproblems gestoßen, sondern weil mein Schlüssel abgelaufen ist. Der einfachste Weg, die Gültigkeit unter OSX zu verlängern, besteht darin, die GPG-Schlüsselbund-App zu öffnen (sofern Sie sie installiert haben), und Sie werden automatisch aufgefordert, sie zu verlängern. Zwei Klicks und fertig. Hoffentlich hilft das anderen Googlern :)

Dies begann plötzlich für mich unter Ubuntu, nicht sicher, ob es ein aktuelles Update getan hat, aber keines der vorhandenen Probleme war für mich zutreffend (ich hatte GPG_TTYfestgelegt, versucht, den Agenten zu töten usw.). Der eigenständige gpgBefehl schlug mit diesem Fehler fehl:

$ echo "test" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

test
gpg: signing failed: Operation cancelled
gpg: [stdin]: clear-sign failed: Operation cancelled

Ich habe versucht, gpgmit --debug-allOption zu laufen und habe die folgende Ausgabe bemerkt:

gpg: DBG: chan_3 <- INQUIRE PINENTRY_LAUNCHED 27472 gnome3 1.1.0 /dev/pts/6 screen-256color -
gpg: DBG: chan_3 -> END
gpg: DBG: chan_3 <- ERR 83886179 Operation cancelled <Pinentry>
gpg: signing failed: Operation cancelled

Das Obige weist darauf hin, dass ein Problem mit dem pinentryProgramm vorliegt. Gpg läuft normalerweise pinentry-cursesfür mich, also habe ich es geändert pinentry-tty(ich musste aptitude installes zuerst tun) und der Fehler ging weg (obwohl ich den Vollbild-Passworteintrag nicht mehr bekomme, aber das gefällt mir trotzdem nicht). Um diese Änderung zu machen, hatte ich die Zeile hinzufügen , pinentry-program /usr/bin/pinentry-ttyum ~/.gnupg/gpg-agent.confmit und zu töten die Agenten gpgconf --kill gpg-agent(es das nächste Mal neu gestartet wird).

Keine der obigen Antworten schien meinem Problem zu entsprechen. Mein gpgbinary ( /usr/local/bin/gpg -> /usr/local/MacGPG2/bin/gpg2) wurde als Teil der GPG Suite installiert und nicht durch Brauen.

Trotzdem hatte ich das Gefühl, dass der Rat sich auf Folgendes beschränkte: "Verwenden Sie die gpgBinärdatei, die die neueste Version von Brew ist". Also habe ich versucht:

brew update
brew upgrade git
brew install gpg

# the following are suggestions from brew's Caveats, to make `/usr/local/bin/gpg`
# point to the brew binary:
rm '/usr/local/bin/gpg'
brew link --overwrite gnupg2

Ich habe überprüft, ob ich die Meldung korrekt geändert gpghabe $PATH, um auf die neue ausführbare Datei von Brew zu verweisen:

🍔 which gpg
/usr/local/bin/gpg
🍔 ls -l /usr/local/bin/gpg
lrwxr-xr-x  1 burger  admin  33 Feb 13 13:22 /usr/local/bin/gpg -> ../Cellar/gnupg2/2.0.30_3/bin/gpg

Und ich habe git auch ausdrücklich gesagt, welche gpgBinärdatei verwendet werden soll:

git config --global gpg.program gpg

Nun, vielleicht ist das nicht ganz wasserdicht, da es empfindlich auf Pfade reagiert. Ich ging nicht so weit, zweifelsfrei zu bestätigen, dass Git auf das Aufrufen des Gebräus umgestellt hatte gpg.

Auf jeden Fall: Nichts davon reichte aus, um git commitmeine Commits erneut erfolgreich zu unterzeichnen.

Die Sache, die für mich letztendlich funktionierte, war das Aktualisieren der GPG Suite . Ich habe Version 2016.7 ausgeführt und festgestellt, dass das Update auf 2016.10 das Problem für mich behoben hat.

Ich öffnete GPG Keychain.appund drückte auf "Nach Updates suchen ...". Mit der neuen Version: Signierte Commits funktionierten wieder korrekt.

habe es eingerichtet durch einfach:

brew uninstall gpg 

brew install gpg2

Sehr ähnlich wie @birchlabs, nach vielem Graben / Suchen stellte ich fest, dass es nicht GPG war, sondern GPG Suite. Ich habe cask reinstall gpg-suitees getan und es hat es für mich gelöst.

Wenn dies nur zufällig passiert ist und in der Vergangenheit wie in meinem Fall einwandfrei funktioniert hat, versuchen Sie, sich abzumelden ( cmd+shift+q) und sich wieder anzumelden. Hat für mich funktioniert

In meinem Fall hat keine der in der anderen Antwort genannten Lösungen funktioniert. Ich fand heraus, dass das Problem spezifisch für ein Repository war. Durch erneutes Löschen und Klonen des Repos wurde das Problem behoben.

Ein bisschen komisch, aber stellen Sie sicher, dass Ihr Terminal groß genug ist! Sie können erkennen, ob es zu klein ist, indem Sie laufenecho test | gpg --clearsign - es gibt Ihnen eine ziemlich offensichtliche Fehlermeldung, die Sie darüber informiert. Wenn es nicht groß genug ist, kann Ihr GPG-Agent sein kleines ncurses-Feld nicht anzeigen.

Dieser gilt nicht, wenn Sie einen GUI-Agenten oder etwas verwenden, das keine Flüche verwendet.