gpg konnte die Daten nicht fatal signieren: Commit-Objekt konnte nicht geschrieben werden

Wenn Sie gnupg2 und gpg-agent 2.x verwenden, stellen Sie sicher, dass Sie die Umgebungsvariable GPG_TTY setzen.

export GPG_TTY=$(tty)

Siehe GPGs Dokumentation zu häufigen Problemen .

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

$ 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, dass mein Schlüssel abgelaufen war. Git war nicht schuld.

Ich habe durch dieses short und easy Rezept gemacht:

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

Holen Sie sich Ihre signingkey in so .

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 gpg.conf-Datei ein (bearbeiten Sie die Datei mit dem Befehl nano ~/.gnupg/gpg.conf):

no-tty

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

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

Kann helfen, den Prozess gpg-agent zu beenden, der möglicherweise mit alten Daten verbunden ist Der neue gpg-agent gestartet würde also nach dem Passwort fragen

Update Okt. 2016: Ausgabe 871 erwähnte "Signing funktioniert nicht mehr in Git 2.9.3"

Git für Windows 2.10.1 Vor zwei Tagen veröffentlicht (4. Oktober 2016) wurde die Interaktive GPG-Signatur von Commits und Tags korrigiert.

die kürzlich erfolgte Änderung des gpg-Zeichens in git (die unter Linux kein Problem darstellt) wirft ein Problem auf, wie nicht-MSYS2-git unter Windows mit MSYS2-gpg interagiert.

Ursprüngliche Antwort:

Wenn Sie " 7.4 Git Tools - Signing Your Work " lesen, gehen Sie davon aus, dass Sie über die Konfiguration " user.signingkey " verfügen.

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

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

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

Für den Verifizierung selbst ist das eigentlich egal: wenn der Die Überprüfung läuft, die PGP-Signatur ist gut.
Aber wenn nicht Sie haben den Schlüssel tatsächlich noch und möchten ihn abrufen, oder Sie möchten .__ überprüfen. Welcher Schlüssel genau zur Verifizierung verwendet wurde und überprüft werden soll, können wir sollte den Schlüssel genauer angeben.

Prüfen Sie also, wie Sie Ihre user.signingkey-Konfiguration und die von Ihnen verwendete gpg-Version (gpg1 oder gpg2) angegeben haben, um zu sehen, ob sich diese auf die Fehlermeldung auswirken.

Es gibt auch commit 0581b54 , das die Bedingung für die gpg failed to sign the data-Fehlermeldung ändert (ergänzend zu commit 0d2b664 ):

Derzeit lesen wir überhaupt nicht von stderr. Allerdings werden wir dies in einem zukünftigen Patch tun wollen, so dass wir uns auch dort vorbereiten werden (und in diesem Fall gpg do _ schreiben, bevor alle Eingaben gelesen werden. Allerdings ist es unwahrscheinlich, dass sich eine Schlüssel-Uid füllen wird einen Pufferspeicher aufstellen).

Commit 4322353 zeigt, dass gpg jetzt eine temporäre Datei verwendet, daher könnte es richtige Probleme geben.

Lassen Sie uns in ein Tempfile-Objekt konvertieren, das die .__ verarbeitet. harte Fälle für uns, und fügen Sie den fehlenden Bereinigungsaufruf hinzu.

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

1. brew uninstall gpg
2. brew install gpg2
3. brew install pinentry-mac (falls erforderlich)
4. gpg --full-generate-key Erstellen Sie einen Schlüssel mithilfe eines Algorithmus.
5. Generierten Schlüssel erhalten durch Ausführen von: gpg --list-keys
6. Setze den Schlüssel hier 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 nach GitHub exportieren möchten, gehen Sie wie folgt vor: gpg --armor --export <key> und fügen Sie diesen Schlüssel unter GPG keys zu GitHub hinzu: https://github.com/settings/keys (mit eingeschlossener 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 signieren Sie den von Ihnen verwendeten Schlüssel, indem Sie Sign in der Menüleiste drücken: Key -> Sign

Wenn das Problem weiterhin besteht:

Gehen Sie zu: Ihrer globalen .gitconfig -Datei, die in meinem Fall folgende Adresse hat: /Users/gent/.gitconfig Und ändern Sie die Datei .gitconfig (Bitte stellen Sie sicher, dass E-Mail und Name mit der von Ihnen übereinstimmen Erstellt beim Generieren des Schlüssels):

[user]
        email = [email protected]
        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 Cents hier:

Beim Erstellen und Hinzufügen eines Schlüssels zu gpg-agent definieren Sie etwas namens passphrase. Nun, da passphrase zu einem bestimmten Zeitpunkt abläuft und gpg Sie erneut eingeben muss, um den Schlüssel zu entsperren, damit Sie erneut mit der Signatur beginnen können.

Wenn Sie ein anderes Programm verwenden, das mit gpg verbunden ist, erscheint not in der Aufforderung zur Eingabe Ihres Passworts (gpg). (Im Prinzip gpg-agent zeigt Ihnen das Eingabedialogfeld in stdin möglicherweise nicht den Eingabedialog an).

Eine der Lösungen ist gpg --sign a_file.txt. Geben Sie dann die Passphrase ein, die Sie beim Erstellen des Schlüssels eingegeben haben, und dann sollte alles in Ordnung sein (gpg-agent sollte automatisch signieren.)

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

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

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

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

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

   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 <[email protected]>'
   error: gpg failed to sign the data
   fatal: failed to write commit object

Ich musste einen Anfangsschlüssel für das Format generieren, mit dem git geprüft wurde. Es ist am besten, den in -bsau übergebenen Wert in den Protokollen unverändert zu kopieren und unten zu verwenden.

So wird es,

   gpg --quick-generate-key "full name <[email protected]>"

Dann hat es funktioniert.

Hoffentlich hilft das.

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

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 brew switch gnupg 1.4.20 ausführen, um die Einstellungen wiederherzustellen.

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

wenn gpg immer noch nicht signiert wurde, ist das Schreiben des Commit-Objekts fehlgeschlagen

dies ist kein Problem mit Git. Dies ist mit GPG. Befolgen Sie die nachstehenden Schritte

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, in dem die PGP-Signatur gespeichert ist.

5. git config -l | grep gpg

gpg.program = gpg commit.gpgsign = true

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

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

Versuchen Sie es mit gpgconf --kill gpg-agentwie hier beschrieben

Wenn die E-Mail, die der Benutzer-ID Ihres GPG-Schlüssels zugeordnet ist, sich von der in git verwendeten E-Mail unterscheidet, müssen Sie Ihrem Schlüssel eine weitere Benutzer-ID hinzufügen OR. Verwenden Sie einen Schlüssel, der genau mit der E-Mail übereinstimmt.

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

$ gpg --edit-key 

Siehe mo https://superuser.com/questions/293184/one-gnupg-pgp-key-pair-two-emails

Ich habe diesen Fehler unter Ubuntu 18.04 bekommen 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 da an habe ich den Ablauf von key 0 und key 1 verlängert, indem ich diese Anweisungen gefolgt von key 0, dann expire und den Eingabeaufforderungen gefolgt habe. Wiederholen Sie dann für key 1.

Danach lief ich, um dies zu testen:

echo test | gpg --clearsign

Und vor dem Update schlug der Fehler fehl:

gpg: Kein geheimer Standardschlüssel: Kein geheimer Schlüssel
gpg: [stdin]: Löschen fehlgeschlagen: Kein geheimer Schlüssel

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

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

Es stellte sich heraus, dass libreadline GnuPG-Probleme bereitete:

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

Der Versuch, nützliche Informationen von Git mit -vvv zu erhalten, ist natürlich fehlgeschlagen, daher war der Fehler ein Rätsel.

Um den PGP-Fehler aufgrund von ReadLine zu beheben, folgen Sie den Anweisungen unter Update nicht möglich oder verwenden Sie den Paket-Manager - gpg-Fehler :

Im Terminal:

ls /usr/local/lib

dort gab es eine Reihe von Readline-Bibliotheken (libreadline.so.BLAH-BLAH) also ich:

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

Ich habe versehentlich gpg irgendwie aktualisiert, weil ich dies nach dem Versuch bekam 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.

Das Ausführen von gpgconf --kill all hat es für mich behoben.

Hoffe das hilft jemandem.

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

git config --global user.email "[email protected]"

Keine der obigen Antworten schien meinem Problem zu entsprechen. Meine gpg-Binärdatei (/usr/local/bin/gpg -> /usr/local/MacGPG2/bin/gpg2) wurde als Teil von GPG Suite und nicht von brew installiert.

Trotzdem hatte ich das Gefühl, dass der Rat lautete: "Verwenden Sie das, was gpg binary ist, das aktuellste auf brauen 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 bestätigt, dass ich die gpg auf meinem $PATH so geändert habe, dass sie auf die neue ausführbare Datei von brew verweist:

???? 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 explizit gesagt, welche gpg-Binärdatei verwendet werden soll:

git config --global gpg.program gpg

Nun, vielleicht ist das nicht völlig wasserdicht, da es pfadempfindlich ist. Ich habe wirklich nicht so weit gegangen, dass ich zweifelsfrei bestätigt habe, dass git zum Aufruf der Brew gpg gewechselt ist.

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

Das, was für mich letztendlich funktioniert hat, war update GPG Suite. Ich habe Version 2016.7 ausgeführt und festgestellt, dass die Aktualisierung auf 2016.10 das Problem für mich behoben hat.

Ich öffnete GPG Keychain.app und drückte auf "Nach Updates suchen ...". Mit der neuen Version funktionierten signierte Commits wieder korrekt.

Die obigen Antworten sind großartig, aber sie haben für mich nicht funktioniert. Was mein Problem gelöst hat, war das Exportieren der Schlüssel public und secret.

liste die Schlüssel von der Maschine auf, von der aus wir exportieren

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

schlüssel exportieren

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

gehen Sie zur Maschine, zu der wir importieren und importieren

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

bingo Bingo, du bist fertig!

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

ps. Meine Schlüssel wurden ursprünglich in Bootcamp Windows 7 erstellt und ich habe sie auf meinen Mac Air exportiert (dieselbe physische Maschine, virtuell anders).

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

git config --global gpg.program gpg

Und tada, es funktioniert wie Charme.

Ihre Commits sind jetzt mit einem bestätigten Tag versehen.

Sehr ähnlich wie @birchlabs. Nach vielem Graben/Suchen habe ich festgestellt, dass es nicht GPG ist, sondern GPG Suite. Ich habe cask reinstall gpg-suite und es wurde für mich gelöst.

habe es einfach eingerichtet:

brew uninstall gpg 

brew install gpg2

Ein bisschen komisch, aber stellen Sie sicher, dass Ihr Terminal groß genug ist! Sie können feststellen, ob es zu klein ist, indem Sie echo test | gpg --clearsign ausführen. Dadurch erhalten Sie eine ziemlich offensichtliche Fehlermeldung, die Sie darüber informiert. Wenn es nicht groß genug ist, kann Ihr GPG-Agent das kleine Feld ncurses nicht anzeigen.

Dieser wird nicht angewendet, wenn Sie einen GUI-Agenten oder etwas verwenden, das keine ncurses verwendet.

Ich habe einige Anregungen ausprobiert, aber kein Glück, und damit endete ich damit. Ich weiß, das ist nicht perfekt, aber ich möchte so schnell wie möglich zu meiner Arbeit zurückkehren.

git config commit.gpgsign false

In meinem Fall hat keine der in anderen Antworten 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.

Wenn dies zufällig geschehen ist und in der Vergangenheit wie in meinem Fall einwandfrei funktioniert hat, melden Sie sich ab (cmd+shift+q) und melden Sie sich wieder an

Ich bin auf diesen Fehler gestoßen, nicht aufgrund eines Konfigurationsproblems, sondern weil mein Schlüssel abgelaufen ist. Die einfachste Möglichkeit, die Gültigkeit unter OSX zu verlängern, besteht darin, die GPG-Schlüsselbund-App zu öffnen (sofern diese installiert ist). Sie werden dann automatisch zur Verlängerung aufgefordert. Mit zwei Klicks sind Sie fertig. Hoffentlich hilft das anderen Googlern :)

Ich habe ähnliche Antworten gesehen, aber nichts genaues wie das, was bei mir funktioniert hat. Unter Linux musste ich meinen gpg-agent töten und neu starten mit:

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

Das hat den Trick für mich getan. Es sieht so aus, als müssten Sie user.signingkey auch auf Ihren privaten Schlüssel setzen, wie einige andere Kommentare besagen.