Vérification des validations git signées?

Avec les nouvelles versions de git il est possible de signer des commits individuels (en plus des tags) avec une key PGP:

 git commit -m "some message" -S 

Et vous pouvez montrer ces signatures dans la sortie de git log avec l'option --show-signature :

 $ git log --show-signature commit 93bd0a7529ef347f8dbca7efde43f7e99ab89515 gpg: Signature made Fri 28 Jun 2013 02:28:41 PM EDT using RSA key ID AC1964A8 gpg: Good signature from "Lars Kellogg-Stedman <lars@seas.harvard.edu>" Author: Lars Kellogg-Stedman <lars@seas.harvard.edu> Date: Fri Jun 28 14:28:41 2013 -0400 this is a test 

Mais existe-t-il un moyen de vérifier par programmation la signature sur un commit donné autre que par grepping la sortie de git log ? Je cherche l'équivalent commit de git tag -v – quelque chose qui fournira un code de sortie indiquant si oui ou non il y avait une signature valide sur un commit donné.

Solutions Collecting From Web of "Vérification des validations git signées?"

Juste au cas où quelqu'un viendrait sur cette page via un moteur de search, comme je l'ai fait: De nouveaux outils ont été mis à disposition dans les deux années depuis la publication de la question: Il existe maintenant des commands git pour cette tâche: git verify-commit et git verify-tag peut être utilisée pour vérifier les validations et les balises, respectivement.

Remarque: jusqu'à git 2.5, git verify-commit et git verify-tag affichaient uniquement un message lisible par l'user.
Si vous voulez automatiser la vérification, git 2.6+ (Q3 2015) ajoute une autre sortie.

Voir commit e18443e , valider aeff29d , valider ca194d5 , valider 434060e , valider 8e98e5f , valider a4cc18f , valider d66aeff (21 juin 2015) par brian m. bk2204 ( bk2204 ) .
(Fusionné par Junio ​​C Hamano – gitster – en cours ba12cb2 , 03 aoû 2015)

verify-tag / verify-commit : ajoute une option pour imprimer les informations d'état raw gpg

verify-tag / verify-commit affiche par défaut une sortie lisible par l'user sur une erreur standard.
Cependant, il peut également être utile d'accéder aux informations brutes d'état gpg, lisibles par machine, permettant une implémentation automatisée de la stratégie de signature .

Ajoutez une option --raw pour que verify-tag produise l'information d'état gpg sur l'erreur standard au lieu du format lisible par l'homme.

Plus:

verify-tag ferme avec succès si la signature est bonne mais la key n'est pas approuvée. verify-commit termine sans succès.
Cette divergence de comportement est inattendue et non désirée.
Comme verify-tag existait auparavant, ajoutez un test qui échoue pour avoir le comportement verify-commit share verify-tag .


git 2.9 (juin 2016) met à jour le document git merge :

Voir comm . 05a5869 (13 mai 2016) par Keller Fuchs (“) .
Aidé par: Junio ​​C Hamano ( gitster ) .
(Fusionné par Junio ​​C Hamano – gitster – in commit be6ec17 , 17 mai 2016)

 --verify-signatures: --no-verify-signatures: 

Vérifiez que la validation tip de la twig latérale fusionnée est signée avec une key valide, c'est-à dire une key ayant un ID user valide: dans le model d'approbation par défaut, cela signifie que la key de signature a été signée par une key approuvée.
Si la validation de pointe de la twig latérale n'est pas signée avec une key valide, la fusion est annulée .


Mettre à jour Git 2.10 (T3 2016)

Voir commit b624a3e (16 août 2016) par Linus Torvalds ( torvalds ) .
(A fusionné par Junio ​​C Hamano – gitster – dans commit 83d9eb0 , 19 août 2016)

gpg-interface : préfère la sortie "long" au format de key lors de la vérification des signatures pgp

" git log --show-signature " et d'autres commands qui affichent l'état de vérification de la signature PGP montrent maintenant l'ID de key plus longue, car l'ID de key 32 bits est donc le siècle dernier.

L'original de Linus a été rebasé pour s'appliquer à la piste de maintenance juste au cas où les dissortingbuteurs binarys qui sont coincés dans le passé veulent l'apporter à leur ancienne base de code.


Git 2.11+ (Q4 2016) sera même plus précis.

Voir commettre 661a180 (12 Oct 2016) par Michael J Gruber ( mjg ) .
(Fusionné par Junio ​​C Hamano – gitstergitster . 56d268b , 26 oct. 2016)

L'état de vérification de GPG indiqué dans le spécificateur de formatting " %G? " N'était pas assez riche pour différencier une signature faite par une key expirée, une signature faite par une key révoquée, etc.
De nouvelles lettres de sortie ont été assignées pour les exprimer .

Selon le doc/DETAILS de gpg2 :

Pour chaque signature, un seul des codes GOODSIG , BADSIG , EXPSIG , EXPKEYSIG , REVKEYSIG ou ERRSIG sera émis.

La documentation git pretty-format comprend maintenant:

  • ' %G? ': montrer
    • " G " pour une bonne signature (valide),
    • " B " pour une mauvaise signature,
    • " U " pour une bonne signature avec une validité inconnue,
    • " X " pour une bonne signature qui a expiré,
    • " Y " pour une bonne signature faite par une key expirée,
    • " R " pour une bonne signature faite par une key révoquée,
    • " E " si la signature ne peut pas être vérifiée (par ex. Clé manquante) et "N" pour aucune signature

Git 2.12 (Q1 2017) " git tag " et " git verify-tag " ont appris à mettre l'état de vérification GPG dans leur format de sortie " --format=<placeholders> " .

Voir commettre 4fea72f , commenter 02c5433 , commenter ff3c8c8 (17 janv. 2017) par Santiago Torres ( SantiagoTorres ) .
Voir commettre 07d347c , commettre 2111aa7 , commenter 94240b9 (17 janv. 2017) par Lukas Puehringer (“) .
(A fusionné avec Junio ​​C Hamano – gitster – en cours 237bdd9 , 31 janv. 2017)

L'ajout de --format à git tag -v coupe la sortie par défaut de la vérification GPG et imprime à la place l'object tag mis en forme.
Cela permet aux appelants de vérifier la balise à partir de refs / tags avec la balise de l'en-tête de l'object tag lors de la vérification GPG.

Une inspection superficielle du code suggère qu'il n'existe pas de méthode directe de ce type.

Tous les tests dans la source git s'appuient sur grep ping la sortie de git show (voir t / t7510-signed-commit.sh pour les tests).

Vous pouvez personnaliser la sortie en utilisant quelque chose comme --pretty "%H %G?%" Pour faciliter l'parsing.

Il semble que vous pouvez requestr à git merge de vérifier une signature, mais encore une fois, ses tests s'appuient sur grep (voir t / t7612-merge-verify-signatures.sh ). Il semblerait qu'une signature invalide entraînera la sortie de git merge avec une mauvaise signature, donc vous pourriez potentiellement contourner ce problème en faisant un test de fusion quelque part et en lançant cette fusion, mais cela semble pire que d'appeler simplement grep.