gpg n’a pas réussi à signer les données fatales: impossible d’écrire l’object de validation

J’ai suivi quelques articles sur les jolis atsortingbuts de la note de version de Git 2.10 . .gitconfig ce qui a mis à niveau le git à 2.10.0 et apporté des modifications au global .gitconfig comme suit –

 [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)%Creset' --abbrev-commit --date=relative [color "diff"] old = red ssortingke new = green italic 

Mais maintenant que j’essaie de signer mes commits en utilisant

 git commit -a -S -m "message" 

Je vois l’erreur suivante –

Vous avez besoin d’une phrase secrète pour déverrouiller la clé secrète pour

utilisateur: “XYZ (signé numériquement)”

Clé RSA 2048 bits, ID AAAAAAAA, créée le 2016-07-01

erreur: gpg impossible de signer le fatal des données: Impossible d’écrire l’object commit

Note – Je peux toujours valider les modifications en utilisant git commit -a -m "message"

Y a-t-il un moyen de surmonter la même chose? Ou tout changement nécessaire dans les configs gpg pour s’entendre avec la mise à niveau de git?


Mise à jour 1

Vous cherchez également plus d’utilité, à la suite Y at-il un moyen de “signer automatiquement” les commits dans Git avec une clé GPG? . J’ai déjà configuré la clé en utilisant

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

et de toute évidence, obtenir la même erreur de toute façon.

J’ai rencontré ce problème avec OSX.

Réponse originale:

Il semblerait qu’une mise à jour de gpg (de brew) soit passée à gpg1 en gpg1 , vous pouvez changer le binary où git recherche gpg:

 git config --global gpg.program gpg1 

Si vous n’avez pas gpg1: brew install gpg1 .

Réponse mise à jour:

Il semblerait que gpg1 soit déprécié / “délicatement déplacé d’usage” , vous devriez donc probablement mettre à jour vers gpg2, malheureusement cela implique pas mal d’étapes / un peu de temps:

 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 

La première partie installe gpg2, et la dernière est un hack requirejs pour l’utiliser . Pour le dépannage, reportez-vous à cette réponse (bien qu’il s’agisse de Linux et non de brew), cela suggère un bon test:

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

Si ce test réussit (aucune erreur / sortie n’inclut la signature PGP), vous avez mis à jour avec succès la dernière version de gpg.

Vous devriez maintenant pouvoir utiliser Git Sign à nouveau!
Il est important de noter que vous devez avoir:

 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 

Remarque: Après avoir exécuté une validation signée, vous pouvez vérifier qu’elle a été signée avec:

 git log --show-signature -1 

qui inclura les informations gpg pour le dernier commit.

Si gnupg2 et gpg-agent 2.x sont utilisés, veillez à définir la variable d’environnement GPG_TTY .

 export GPG_TTY=$(tty) 

Voir la documentation de GPG sur les problèmes courants .

Si tout échoue, utilisez GIT_TRACE=1 pour essayer de voir ce que git est en train de faire:

 $ 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 

Maintenant, exécutez manuellement la commande défaillante:

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

Il s’avère que ma clé a expiré, git n’était pas à blâmer.

Je l’ai fait grâce à cette recette courte et facile :

La signature automatique est validée sur MacOS (globalement et avec différents IDE):

Obtenez votre signingkey de cette façon .

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

Placez le fichier suivant dans le fichier gpg.conf (fichier d’édition avec la commande nano ~/.gnupg/gpg.conf ):

 no-tty 

Placez ce qui suit dans le fichier gpg-agent.conf (fichier d’édition avec la commande nano ~/.gnupg/gpg-agent.conf ):

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

Peut aider à tuer le processus gpg-agent qui pourrait restr avec d’anciennes données. Donc, un nouvel gpg-agent commencé demanderait un mot de passe

Mise à jour d’octobre 2016: le numéro 871 mentionnait “La signature a cessé de fonctionner dans Git 2.9.3”

Git for Windows 2.10.1 publié il y a deux jours (4 octobre 2016) a corrigé la signature interactive GPG des commits et des balises.

Le récent changement de gpg-sign dans git (qui n’introduit aucun problème sous Linux) expose un problème dans la manière dont, sous Windows, non-MSYS2-git interagit avec MSYS2-gpg.


Réponse originale:

En lisant ” 7.4 Git Tools – Signing Your Work “, je suppose que vous avez votre configuration ” user.signingkey “.

Le dernier gros refactoring (avant Git 2.10) autour de gpg était dans commit 2f47eae2a , ici ce message d’erreur a été déplacé dans gpg-interface.c

Un journal sur ce fichier révèle le récent changement dans commit af2b21e (Git 2.10)

gpg2 utilise déjà le format long par défaut, mais la plupart des dissortingbutions semblent toujours avoir l’ancienne version 1.x de “gpg” pour des raisons de compatibilité. Et les anciennes versions de gpg ne montrent que l’ID court de 32 bits, ce qui est assez peu sûr.

Cela n’a pas vraiment d’importance pour la vérification elle-même: si la vérification réussit, la signature pgp est bonne.
Mais si vous ne possédez pas encore la clé, et que vous voulez la récupérer, ou si vous voulez vérifier exactement quelle clé a été utilisée pour la vérification et que vous voulez la vérifier, vous devez spécifier la clé avec plus de précision.

Vérifiez donc comment vous avez spécifié votre configuration user.signingkey et la version de gpg que vous utilisez (gpg1 ou gpg2), pour voir si celles-ci ont un effet sur le message d’erreur.

Il y a aussi la validation 0581b54 qui modifie la condition pour le gpg failed to sign the data message d’erreur de gpg failed to sign the data (en complément pour valider 0d2b664 ):

Nous ne lisons pas du tout de stderr actuellement. Cependant, nous voudrons le faire dans un futur patch, donc cela nous prépare également (et dans ce cas, gpg écrit avant de lire toutes les entrées, mais encore une fois, il est peu probable qu’un uid de clé remplisse un tampon de tube).

Commit 4322353 montre que gpg utilise maintenant un fichier temporaire, il pourrait donc y avoir des problèmes à ce sujet.

Convertissons en utilisant un object tempfile, qui gère les cas difficiles pour nous, et ajoutons l’appel de nettoyage manquant.

J’ai rencontré le même problème. Je suis heureux de signaler que le problème ne réside pas dans git 2.10.0 mais avec gnupg 1.4.21 .

Rétrograder temporairement gnupg à 1.4.20 a résolu le problème pour moi.

Si vous utilisez l’homebrew et que vous avez mis à jour vos paquets comme je l’ai fait, vous pouvez probablement lancer brew switch gnupg 1.4.20 pour revenir en arrière.

En utilisant cygwin, je suis récemment passé à gpg2 . Ensuite, j’ai eu le même problème pour signer avec git après avoir défini git config gpg.program gpg2 .

Essayez echo "test" | gpg2 --clearsign echo "test" | gpg2 --clearsign pour voir si gpg2 fonctionne. Je l’ai trouvé la solution la plus simple pour définir git config gpg.program gpg , car cela fonctionne. Mais vous obtiendrez également une meilleure erreur de cette manière – par exemple, vous devez installer Pinentry.

Si l’e-mail associé à l’ID de votre clé GPG est différent de celui que vous utilisez dans git, vous devrez append un autre ID utilisateur à votre clé OU utiliser une clé qui correspond exactement à l’e-mail.

Vous pouvez append un autre UID en utilisant:

$ gpg –edit-key

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

Assurez-vous que votre messagerie est correctement configurée.

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

J’ai eu un problème similaire avec les dernières sources Git (2.12.2) construites avec les dernières sources de toutes ses dépendances (Zlib, Bzip, cURL, PCRE, ReadLine, IDN2, iConv, Unissortingng, etc.).

Il s’avère que libreadline donnait des problèmes à GnuPG:

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

Et bien sûr, essayer d’obtenir des informations utiles de Git avec -vvv échoué, donc l’échec était un mystère.

Pour résoudre l’échec de PGP dû à ReadLine, suivez les instructions de la section Impossible de mettre à jour ou d’utiliser le gestionnaire de paquets – erreur gpg :

Dans le terminal:

 ls /usr/local/lib 

il y avait un tas de librairies de readline là-dedans (libreadline.so.BLAH-BLAH) donc je:

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

J’ai essayé pas mal de suggestions mais pas de chance, et j’ai fini par ça. Je sais que ce n’est pas parfait, mais je veux juste revenir à mon travail dès que possible.

 git config commit.gpgsign false 

Mes deux cents ici:

Lorsque vous créez et ajoutez une clé à gpg-agent, vous définissez quelque chose appelé passphrase . Maintenant que la passphrase expire à un moment donné, gpg besoin que vous la gpg à nouveau pour déverrouiller votre clé afin de pouvoir recommencer à signer.

Lorsque vous utilisez un autre programme qui s’interface avec gpg , l’invite de gpg-agent vous demandant d’entrer votre phrase secrète n’apparaît pas (en gros, gpg-agent lorsque le démon ne peut pas afficher la boîte de dialog d’entrée dans stdin ).

Une des solutions est gpg --sign a_file.txt puis entrez la phrase secrète que vous avez entrée lors de la création de votre clé et tout devrait bien se gpg-agent ( gpg-agent devrait automatiquement signer)

Voir cette réponse sur la façon de définir des délais plus longs pour votre phrase secrète afin de ne pas avoir à le faire tout le temps.

Ou vous pouvez supprimer complètement la phrase secrète avec ssh-keygen -p

Les réponses ci-dessus sont excellentes mais elles n’ont pas fonctionné pour moi. Ce qui a résolu mon problème, c’était d’exporter les clés publiques et secrètes .

lister les clés de la machine d’où nous exportons

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

exporter les clés

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

aller à la machine que nous importons et importons

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

bingo bongo, vous avez terminé!

référence: https://www.debuntu.org/how-to-importexport-gpg-key-pair/

ps. Mes clés ont été initialement créées sur bootcamp windows 7 et je les ai exscopes sur mon mac air (même machine physique, différente virtuellement)

Il a été configuré simplement par:

 brew uninstall gpg brew install gpg2 

Vérifiez si gpg est activé en utilisant la commande ci-dessous

 git config -l | grep gpg 

s’il renvoie true, exécutez la commande ci-dessous pour le désactiver

 git config --global --unset commit.gpgsign 

Après avoir exécuté avec succès la commande ci-dessus, vous devriez pouvoir exécuter la commande git commit.

Tout comme @birchlabs, après de nombreuses recherches et fouilles, j’ai constaté que ce n’était pas du GPG, mais plutôt du GPG Suite. J’ai fait cask reinstall gpg-suite et cela a résolu le problème pour moi.

Aucune des réponses ci-dessus ne semblait correspondre à mon problème. Mon fichier binary gpg ( /usr/local/bin/gpg -> /usr/local/MacGPG2/bin/gpg2 ) a été installé dans le cadre de GPG Suite plutôt que par infusion.

Néanmoins, j’estimais que le conseil se résumait à: “utiliser le binary gpg le plus récent disponible sur brew”. J’ai donc essayé:

 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 

J’ai vérifié que j’avais correctement modifié le gpg sur mon $PATH pour pointer vers le nouvel exécutable de brew:

 🍔 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 

Et j’ai aussi explicitement dit à git quel fichier binary gpg utiliser:

 git config --global gpg.program gpg 

Eh bien, peut-être que ce n’est pas complètement étanche, car il est sensible au chemin. En fait, je ne suis pas allé aussi loin que confirmer sans le moindre doute que git avait opté pour l’invocation du gpg .

En tout cas, rien de tout cela ne suffisait pour que git commit réussisse à signer à nouveau mes commits.


La chose qui a fonctionné pour moi au final était de mettre à jour GPG Suite . J’étais en cours d’exécution avec la version 2016.7 et j’ai constaté que la mise à jour vers 2016.10 avait résolu le problème pour moi.

J’ai ouvert GPG Keychain.app et cliquez sur “Vérifier les mises à jour…”. Avec la nouvelle version: les commits signés fonctionnaient à nouveau correctement.

Si cela venait juste de se passer au hasard et que cela fonctionnait parfaitement dans le passé, comme c’est mon cas, essayez de vous déconnecter ( cmd+shift+q ) et de vous reconnecter.

Dans mon cas, aucune des solutions mentionnées dans les autres réponses n’a fonctionné. J’ai découvert que le problème était spécifique à un référentiel. La suppression et le clonage du repository ont à nouveau résolu le problème.