gpg n'a pas pu signer la donnée fatal: impossible d'écrire un objet de validation [Git 2.10.0]
J'ai suivi quelques articles sur la jolie attributs sur Git 2.10 release note. Passant en revue qui a mis à jour le git à la version 2.10.0 et apporté les modifications au .gitconfig global résultant comme suit -
[filter "lfs"]
clean = git-lfs clean %f
smudge = git-lfs smudge %f
required = true
[user]
name = xyz
email = [email protected]
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
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
utilisateur: "XYZ (signé numériquement)"
Clé RSA 2048 bits, ID AAAAAAAA, créée le 2016-07-01
error: gpg n'a pas pu signer les données fatales: impossible d'écrire commit objet
Note - Je peux toujours valider les modifications à l'aide de git commit -a -m "message"
Y a-t-il un moyen de surmonter le même problème? Ou tout changement nécessaire dans les configurations gpg pour s'entendre avec la mise à jour de git?
Mise à jour 1
Cherchant également plus d’utilité, après Existe-t-il un moyen de "signer automatiquement" des 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 bien évidemment obtenir la même erreur de toute façon.
J'ai rencontré ce problème avec OSX.
Réponse originale:
Cela ressemble à une mise à jour de gpg (de brew) modifiée à l'emplacement de gpg en gpg1, vous pouvez changer le binaire où git recherche le 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 obsolète / "il a été légèrement abandonné" , vous devriez donc probablement mettre à jour gpg2; malheureusement, cela implique quelques étapes supplémentaires/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 nécessaire pour l’utiliser . Pour le dépannage, voir cette réponse (bien que ce soit à propos de Linux et non de la bière), 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 ne comprend la signature PGP), vous avez mis à jour avec succès la dernière version de gpg.
Vous devriez maintenant pouvoir utiliser la signature git à nouveau!
Il convient 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 la vérifier 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)
Si tout échoue, utilisez GIT_TRACE=1 pour voir ce que git fait réellement:
$ 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 la commande qui échoue manuellement:
$ gpg -bsau 23810377252EF4C2
gpg: skipped "23810377252EF4C2": Unusable secret key
gpg: signing failed: Unusable secret key
Il s'avère que ma clé était expirée, ce n'était pas à blâmer.
Je l'ai FAIT à travers cette recette short et easy:
La signature automatique est validée sur MacOS (globalement et avec différents IDE):
Obtenez votre signingkey dans de cette façon .
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
Placez ce qui suit dans le fichier gpg.conf (modifiez le fichier avec la commande nano ~/.gnupg/gpg.conf):
no-tty
Placez ce qui suit dans le fichier gpg-agent.conf (modifiez le fichier avec la commande nano ~/.gnupg/gpg-agent.conf):
pinentry-program /usr/local/bin/pinentry-mac
Peut aider à tuer le processus gpg-agent qui pourrait rester avec de vieilles données. Donc, le nouveau gpg-agent commencé demanderait un mot de passe
Mise à jour octobre 2016: numéro 871 a mentionné "La signature a cessé de fonctionner dans Git 2.9.3"
Git pour Windows 2.10.1 publié il y a deux jours (le 4 octobre 2016) a corrigé la signature Interactive GPG des commits et des balises.
le récent changement de signe gpg dans git (qui ne pose aucun problème sous Linux) pose un problème dans la façon dont, sous Windows, les non-MSYS2-git interagissent avec MSYS2-gpg.
Réponse originale:
Reading " 7.4 Outils Git - Signing Your Work ", je suppose que vous avez votre " user.signingkey " ensemble de configuration.
Le dernier grand 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 la récente modification de commit af2b21e (Git 2.10)
gpg2 utilise déjà le format long par défaut, mais la plupart des distributions semblent toujours utiliser "gpg" comme étant l'ancienne version 1.x pour des raisons de compatibilité. Et les anciennes versions de gpg ne montrent que l’ID court 32 bits, ce qui n’est pas sûr.
Cela n'a pas vraiment d'importance pour le verification lui-même: si le la vérification passe, la signature pgp est bonne.
Mais si vous ne le faites pas avez encore la clé et voulez la récupérer, ou vous voulez vérifier quelle clé a été utilisée pour la vérification et que vous voulez vérifier, nous devrait 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 s’ils ont un effet sur le message d’erreur.
Il existe également commit 0581b54 qui modifie la condition du message d'erreur gpg failed to sign the data (en complément de commit 0d2b664 ):
Nous ne lisons pas du tout de stderr pour le moment. Cependant, nous le voudrons dans un futur patch, donc cela nous prépare également là-bas (et dans ce cas, gpg ne écrit avant de lire toutes les entrées, bien que là encore, il est peu probable qu'un uid clé remplisse tuyau tampon).
Commit 4322353 montre que gpg utilise maintenant un fichier temporaire, ce qui pourrait poser problème.
Convertissons maintenant en utilisant un objet tempfile, qui gère le fichier cas difficiles pour nous, et ajouter l'appel de nettoyage manquant.
Pour tous ceux qui font face à ce problème sur MacOS machines, essayez ceci:
brew uninstall gpgbrew install gpg2brew install pinentry-mac(si nécessaire)gpg --full-generate-keyCréez une clé à l'aide d'un algorithme.- Obtenir la clé générée en exécutant:
gpg --list-keys - Placez la clé ici
git config --global user.signingkey <Key from your list> git config --global gpg.program /usr/local/bin/gpggit config --global commit.gpgsign true- Si vous voulez exporter votre clé vers GitHub, alors:
gpg --armor --export <key>et ajoutez cette clé à GitHub à l'aide des clés GPG: https://github.com/settings/keys (avec les lignes START et END incluses)
Si le problème persiste:
test -r ~/.bash_profile && echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile
echo 'export GPG_TTY=$(tty)' >> ~/.profile
Si le problème persiste:
Installez https://gpgtools.org et signez la clé que vous avez utilisée en appuyant sur Sign dans la barre de menus: Key -> Signer
Si le problème persiste:
Allez à: votre fichier .gitconfig global qui, dans mon cas, se trouve à: /Users/gent/.gitconfig et modifiez le. Gitconfig fichier veuillez vous assurer que les champs Email et Nom sont identiques à celui que vous avez créé lors de la génération de la clé)} _:
[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 = osxkeychainMes deux cents ici:
Lorsque vous créez et ajoutez une clé à gpg-agent, vous définissez un élément appelé passphrase. Maintenant que passphrase expire à un moment donné et que gpg a besoin de vous pour la saisir à 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 vous invite à entrer votre phrase secrète n'est pas s'affiche (fondamentalement gpg-agent lorsque démonisé ne peut pas vous montrer le dialogue de saisie 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é. Tout devrait bien se passer (gpg-agent doit signer automatiquement).
Voir cette réponse sur la façon de définir des délais plus longs pour votre phrase secrète afin que vous n’ayez pas à le faire tout le temps.
Ou vous pouvez supprimer complètement la phrase secrète avec ssh-keygen -p
En utilisant cygwin, je suis récemment passé à gpg2. Ensuite, j'ai eu le même problème de signature avec git après la définition de git config gpg.program gpg2.
Essayez echo "test" | gpg2 --clearsign pour voir si gpg2 fonctionne. Je trouvais la solution la plus simple pour définir simplement git config gpg.program gpg, car cela fonctionne. Mais vous obtiendrez également une meilleure erreur de cette façon - par exemple. que vous devez installer pinentry.
La trace de git était très révélatrice pour ma 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
Je devais générer une clé initiale selon le format que git vérifiait. Il est préférable de copier la valeur passée à -bsau ci-dessus dans les journaux telle quelle et de l'utiliser ci-dessous.
Alors ça devient,
gpg --quick-generate-key "full name <[email protected]>"
Ensuite cela a fonctionné.
J'espère que cela pourra aider.
J'ai rencontré le même problème. Je suis heureux d'annoncer que le problème ne réside pas dans git 2.10.0 mais avec gnupg 1.4.21.
La rétrogradation temporaire de gnupg à la version 1.4.20 a résolu le problème pour moi.
Si vous utilisez homebrew et que vous avez mis à niveau vos paquets comme je l'ai fait, vous pouvez probablement exécuter brew switch gnupg 1.4.20 pour revenir en arrière.
Suivez l’URL ci-dessous pour configurer le commit signé https://help.github.com/fr/articles/telling-git-about-your-signing-key
si toujours obtenir gpg n'a pas réussi à signer les données fatal: impossible d'écrire un objet de validation
ce n'est pas un problème avec git, c'est avec GPG suivez les étapes ci-dessous
1 .gpg --version
echo "test" | gpg --clearsign
si elle montre:
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
- puis utilisez
export GPG_TTY=$(tty)
4. Puis essayez à nouveau echo "test" | gpg --clearsign dans lequel la signature PGP est obtenue.
git config -l | grep gpg
gpg.program = gpg commit.gpgsign = true
6.appliquez git commit -S -m "commitMsz"
Peut-être un gpg-agent suspendu.
Essayez gpgconf --kill gpg-agentcomme discuté ici
Si l'email associé à l'ID de votre clé GPG est différent de l'email que vous utilisez dans git, vous devrez ajouter un autre identifiant utilisateur à votre clé OR, utilisez une clé dont l'adresse correspond exactement.
Vous pouvez ajouter un autre UID en utilisant:
$ gpg --edit-key
Voir pour mo https://superuser.com/questions/293184/one-gnupg-pgp-key-pair-two-emails
J'ai eu cette erreur sur Ubuntu 18.04 et il s'est avéré que ma clé était expirée .
Pour voir cela, j'ai exécuté ceci et il a été confirmé que mes clés avaient expiré:
gpg --list-keys
Pour corriger cela, j'ai couru (en utilisant l'ID affiché dans la commande précédente):
gpg --edit-key <ID>
À partir de là, j'ai prolongé l'expiration de key 0 et key 1 après ces instructions , ce qui revient à taper key 0 puis expire et à suivre les invites. Puis répétant pour key 1.
Ensuite, pour tester cela, j'ai lancé:
echo test | gpg --clearsign
Et avant le correctif, il a échoué avec l'erreur:
gpg: pas de clé secrète par défaut: pas de clé secrète
gpg: [stdin]: échec de la signature dégagée: pas de clé secrète
Mais après le correctif, la même commande a signé le message avec succès, alors je savais que tout allait bien fonctionner à nouveau!
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, Unistring, etc.).
libreadline posait 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 a échoué. L'échec était donc un mystère.
Pour résoudre l’échec de PGP dû à ReadLine, suivez les instructions qui se trouvent à Impossible de mettre à jour ou d’utiliser le gestionnaire de paquets - erreur gpg :
En terminal:
ls /usr/local/libil y avait un tas de bibliothèques readline (libreadline.so.BLAH-BLAH) donc je:
su mkdir temp mv /usr/local/lib/libreadline* temp ldconfig
Je dois avoir accidentellement mis à jour gpg parce que je l’ai obtenu après avoir essayé de vérifier si gpg fonctionnait:
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.
Courir gpgconf --kill all l'a corrigé pour moi.
J'espère que ça aide quelqu'un.
Assurez-vous que votre courrier électronique est correctement défini.
git config --global user.email "[email protected]"
Aucune des réponses ci-dessus ne semblait correspondre à mon problème. Mon binaire gpg (/usr/local/bin/gpg -> /usr/local/MacGPG2/bin/gpg2) a été installé dans le cadre de GPG Suite , plutôt que par brew.
Néanmoins, j’ai senti que le conseil se résumait à: "utilisez le binaire gpg est le dernier en date disponible sur brew". Alors j'ai 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 changé la gpg de mon $PATH pour indiquer 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 binaire gpg utiliser:
git config --global gpg.program gpg
Bien, peut-être que ce n'est pas complètement étanche, car c'est sensible au chemin. En réalité, je n’ai pas été aussi loin que de confirmer avec certitude que git était passé à invoquer la bière gpg.
Dans tous les cas: rien de tout cela n'était suffisant pour que git commit signe à nouveau correctement mes commits.
Ce qui a finalement fonctionné pour moi a été de mettre à jour GPG Suite. J'utilisais la version 2016.7 et j'ai constaté que la mise à jour vers 2016.10 corrigeait le problème.
J'ai ouvert GPG Keychain.app et cliqué sur «Vérifier les mises à jour…». Avec la nouvelle version: les validations signées fonctionnaient à nouveau correctement.
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 public et secret.
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) <[email protected]>
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 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é créées à l’origine sur Bootcamp Windows 7 et je les ai exportées sur mon Mac Air (même machine physique, pratiquement différente).
Je suis sur Ubuntu 18.04 et j'ai la même erreur, j'étais inquiet pendant des semaines aussi. Finalement réalisé que gpg2 ne pointe vers rien. Donc simplement courir
git config --global gpg.program gpg
Et tada, ça marche comme un charme.
Vos commits auront maintenant tag vérifié avec eux.
Tout comme @birchlabs, après de nombreuses recherches et recherches, j'ai découvert que ce n'était pas GPG, mais plutôt GPG Suite. J'ai fait cask reinstall gpg-suite et cela a résolu le problème pour moi.
je l'ai configuré simplement:
brew uninstall gpg
brew install gpg2
Un peu bizarre, mais assurez-vous que votre terminal est assez grand! Vous pouvez savoir s'il est trop petit en exécutant echo test | gpg --clearsign - un message d'erreur assez évident vous en avertira. Si cela ne suffit pas, votre agent GPG ne peut pas afficher sa petite boîte ncurses.
Celui-ci ne s'appliquera pas si vous utilisez un agent d'interface graphique ou quelque chose qui n'utilise pas ncurses.
J'ai essayé pas mal de suggestions mais pas de chance et je me suis retrouvé avec ça. Je sais que ce n'est pas parfait, mais je veux juste reprendre mon travail au plus vite.
git config commit.gpgsign false
Dans mon cas, aucune des solutions mentionnées dans une autre réponse n'a fonctionné. J'ai découvert que le problème était spécifique à un référentiel. La suppression et le clonage du référentiel ont à nouveau résolu le problème.
Si cela s'est produit de manière aléatoire et a parfaitement fonctionné dans le passé, comme c'est mon cas, essayez de vous déconnecter (cmd+shift+q) et de vous reconnecter. A travaillé pour moi
Je suis tombé sur cette erreur, pas à cause d’un problème de configuration, mais parce que ma clé a expiré. Le moyen le plus simple d’étendre sa validité sur OSX est d’ouvrir l’application GPG Keychain (si vous l’avez installée) et elle vous demandera automatiquement de l’étendre. Deux clics et vous avez terminé. Espérons que cela aide les autres Googlers :)
J'ai vu des réponses similaires, mais rien ne ressemble exactement à ce qui a fonctionné pour moi. Sous Linux, je devais tuer et redémarrer mon gpg-agent avec:
$ pkill gpg-agent
$ gpg-agent --daemon
$ git commit ...
Cela a fait le tour pour moi. Il semble que vous ayez également besoin que user.signingkey soit défini sur votre clé privée à partir de ce que disent certains commentaires.