Note : jusqu'à git 2.5, git verify-commit y git verify-tag n'a affiché qu'un message lisible par l'homme.
Si vous voulez automatiser la vérification, git 2.6+ (Q3 2015) ajoute une autre sortie.
Voir commettre e18443e , commettre aeff29d , commettre ca194d5 , commettre 434060e , commettre 8e98e5f , commettre a4cc18f , commettre d66aeff (21 juin 2015) par brian m. carlson ( bk2204 ) .
(fusionné par Junio C Hamano -- gitster -- en commettre ba12cb2 , 03 Aug 2015)
verify-tag / verify-commit : ajouter une option pour imprimer les informations brutes sur le statut de gpg
verify-tag / verify-commit affiche par défaut une sortie lisible par l'homme sur l'erreur standard.
Cependant, il peut également être utile d'avoir accès aux informations brutes sur le statut de gpg, qui sont lisibles par machine, ce qui permet une mise en œuvre automatisée de la politique de signature. .
Ajouter un --raw option de faire verify-tag produire les informations d'état de gpg sur l'erreur standard au lieu du format lisible par l'homme.
Plus :
verify-tag se termine avec succès si la signature est bonne mais la clé est non fiable. verify-commit sort sans succès.
Cette divergence de comportement est inattendue et non souhaitée.
Desde verify-tag existait plus tôt, ajoutez un test d'échec pour avoir verify-commit action verify-tag Le comportement de l'entreprise.
git 2.9 (juin 2016) met à jour le fichier git merge doc :
Voir commettre 05a5869 (13 mai 2016) par Keller Fuchs (``) .
Aidé par : Junio C Hamano ( gitster ) .
(fusionné par Junio C Hamano -- gitster -- en commettre be6ec17 , 17 mai 2016)
--verify-signatures:
--no-verify-signatures:
Vérifiez que le dernier commit de la branche latérale en cours de fusion est signé avec une clé valide, c'est à dire une clé qui a un uid valide : dans le modèle de confiance par défaut, cela signifie que la clé de signature a été signée par une clé de confiance.
Si le dernier commit de la branche latérale n'est pas signé avec une clé valide, la fusion est interrompue. .
Mise à jour Git 2.10 (Q3 2016)
Voir commettre b624a3e (16 août 2016) par Linus Torvalds ( torvalds ) .
(fusionné par Junio C Hamano -- gitster -- en commettre 83d9eb0 , 19 août 2016)
gpg-interface : préférez la sortie du format de clé "long" lors de la vérification des signatures pgp
" git log --show-signature "et d'autres commandes qui affichent l'état de vérification de la signature PGP montrent maintenant l'identifiant de clé le plus long, car l'identifiant de clé de 32 bits est tellement du dernier siècle.
L'original de Linus a été reformulé pour s'appliquer à la voie de la maintenance, juste au cas où les distributeurs de binaires qui sont bloqués dans le passé voudraient l'appliquer à 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 -- gitster -- en commettre 56d268b , 26 oct. 2016)
L'état de vérification GPG indiqué dans " %G? Le spécificateur de format "pretty" n'était pas assez riche pour différencier une signature faite par une clé expirée, une signature faite par une clé révoquée, etc.
De nouvelles lettres de sortie ont été attribuées pour les exprimer .
Selon de gpg2 doc/DETAILS :
Pour chaque signature, un seul des codes GOODSIG , BADSIG , EXPSIG , EXPKEYSIG , REVKEYSIG ou ERRSIG sera émise.
El git pretty-format documentation comprennent désormais :
- '
%G? ' : spectacle
- "
G " pour une bonne signature (valide),
- "
B " pour une mauvaise signature,
- "
U " pour une bonne signature dont la validité est inconnue,
- "
X " pour une bonne signature qui a expiré,
- "
Y " pour une bonne signature faite par une clé expirée,
- "
R " pour une bonne signature faite par une clé révoquée,
- "
E "si la signature ne peut pas être vérifiée (par exemple, clé manquante). et " N "pour aucune signature
Git 2.12 (1er trimestre 2017) " git tag " et " git verify-tag " ont appris à mettre l'état de vérification GPG dans leur " --format=<placeholders> "Format de sortie .
Voir commettre 4fea72f , commettre 02c5433 , commettre ff3c8c8 (17 janvier 2017) par Santiago Torres ( SantiagoTorres ) .
Voir commettre 07d347c , commettre 2111aa7 , commettre 94240b9 (17 janvier 2017) par Lukas Puehringer (``) .
(fusionné par Junio C Hamano -- gitster -- en commit 237bdd9 , 31 janvier 2017)
Ajout de --format a git tag -v désactive la sortie par défaut de la GPG et imprime à la place l'objet balise formaté.
Cela permet aux appelants de vérifier le nom de famille à partir de refs/tags avec le nom de domaine de l'en-tête de l'objet balise lors de la vérification GPG.
Git 2.16 (Q1 2018) permettra d'automatiser encore davantage la vérification de la signature des commit, avec la fonction merge.verifySignatures variable de configuration.
Voir commettre 7f8ca20 , commettre ca779e8 (10 déc. 2017) par Hans Jerry Illikainen (``) .
(fusionné par Junio C Hamano -- gitster -- en commettre 0433d53 , 28 déc. 2017)
merge : ajouter une option de configuration pour verifySignatures
git merge --verify-signatures peut être utilisé pour vérifier que le tip commit de la branche en cours de fusion est correctement signé, mais il est fastidieux de de devoir le spécifier à chaque fois.
Ajouter une option de configuration qui active ce comportement par défaut, qui peut être remplacée par --no-verify-signatures .
El git merge page de manuel de configuration se lit maintenant :
merge.verifySignatures:
Si c'est le cas, cela équivaut à l'option --verify-signatures option de ligne de commande.
Git 2.19 (Q3 2018) est encore plus utile, puisque " git verify-tag " et " git verify-commit "On a appris à utiliser le statut de sortie du sous-jacent " gpg --verify " pour signaler une signature mauvaise ou non fiable qu'ils ont trouvée.
Note : avec Git 2.19, gpg.format qui peut être réglé sur " openpgp " ou " x509 ", et gpg.<format>.program qui est utilisé pour spécifier le programme à utiliser pour traiter le format) pour autoriser les certificats x.509 avec CMS via " gpgsm " à utiliser au lieu de openpgp via " gnupg ".
Voir commettre 4e5dc9c (09 août 2018) par Junio C Hamano ( gitster ) .
Aidé par : Vojtech Myslivec ( VojtechMyslivec ) , brian m. carlson ( bk2204 ) y Jeff King ( peff ) .
(fusionné par Junio C Hamano -- gitster -- en commettre 4d34122 , 20 août 2018)
gpg-interface Propagation de l'état de sortie à partir de gpg retour aux appelants
Lorsque l'API gpg-interface a unifié la prise en charge des chemins de code de vérification des signatures pour les tags signés et les commits signés au milieu de l'année 2015, aux alentours de la v2.6.0-rc0~114, nous avons accidentellement relâché la vérification des signatures GPG.
Avant ce changement, les commits signés étaient vérifiés en cherchant " G "ood signature from GPG, while ignoring the exit status of " gpg --verify "tandis que les balises signées étaient vérifiées en passant simplement l'état de sortie du processus "gpg --verify " à travers.
Le code unifié que nous avons actuellement ignore le statut de sortie de " gpg --verify "et renvoie une vérification réussie lorsque la signature correspond à une clé non expirée, quelle que soit la confiance accordée à la clé (c'est-à-dire en plus de " G "Les bons, nous acceptons" U "ntrusted ones").
Faites en sorte que ces commandes signalent l'échec avec leur état de sortie lorsque sous-jacent " gpg --verify "(ou la commande personnalisée spécifiée par " gpg.program ") le fait.
Cela change essentiellement leur comportement d'une manière incompatible avec le passé pour rejeter les signatures qui ont été faites avec des clés non fiables même si elles sont correctement vérifiées, car c'est ainsi que " gpg --verify "se comporte.
Notez que le code remplace toujours un état de sortie nul obtenu par " gpg "(ou gpg.program ) si la sortie ne dit pas que la signature est bonne ou qu'elle se calcule correctement mais qu'elle a été faite avec des clés non fiables, pour attraper une enveloppe mal écrite autour de " gpg " que l'utilisateur peut nous donner.
Nous pourrions exclure " U "ntrusted support" à partir de ce code de repli, mais cela reviendrait à faire deux changements incompatibles avec le passé dans un seul commit, donc évitons cela pour le moment.
Un changement de suivi pourrait le faire si on le souhaite.
la clé doit être approuvée/signée avant de procéder au cryptage.
Du côté de la confiance, il y a du progrès :
Avec Git 2.26 (Q1 2020), gpg.minTrustLevel a été introduite pour indiquer aux différents chemins de code de vérification des signatures le niveau de confiance minimum requis.
Voir commettre 54887b4 (27 déc. 2019) par Hans Jerry Illikainen ( illikainen ) .
(fusionné par Junio C Hamano -- gitster -- en commettre 11ad30b , 30 janvier 2020)
gpg-interface : ajouter minTrustLevel comme option de configuration
Signé par : Hans Jerry Illikainen
Auparavant, la vérification de la signature pour les opérations de fusion et d'extraction vérifiait si la clé avait un niveau de confiance de l'une ou l'autre des valeurs suivantes TRUST_NEVER ou TRUST_UNDEFINED en verify_merge_signature() .
Si c'était le cas, le processus die() 'd.
Les autres chemins de code qui effectuaient la vérification des signatures s'appuyaient entièrement sur le code de retour de l'application check_commit_signature() .
Et les signatures faites avec une bonne clé, quel que soit son niveau de confiance, étaient considérées comme valides par check_commit_signature() .
Cette différence de comportement pourrait incitent les utilisateurs à supposer à tort que le niveau de confiance d'une clé dans leur trousseau est toujours pris en compte par Git, même pour les opérations où ce n'est pas le cas (par exemple, lors d'une opération d'authentification). verify-commit ou verify-tag ) .
Le système fonctionne de la manière suivante gpg-interface.c stockage du résultat de l'état de la clé/signature et les deux niveaux de confiance les plus bas dans le result membre de la signature_check (la dernière de ces lignes d'état rencontrées est écrite dans le fichier result ).
Ceux-ci sont documentés dans GPG sous la sous-section General status codes y Key related respectivement.
La documentation GPG dit ce qui suit sur le TRUST_ status codes :
Il s'agit de plusieurs codes d'état similaires :
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
Pour les bonnes signatures, une de ces lignes d'état est émise pour indiquer la validité de la clé utilisée pour créer la signature.
Les valeurs des jetons d'erreur ne sont actuellement émises que par gpgsm.
Mon interprétation est que le niveau de confiance est conceptuellement différent de la validité de la clé et/ou de la signature.
Il semble que ce soit également l'hypothèse de l'ancien code en check_signature() où un résultat de ' G (comme dans GOODSIG ) et U (comme dans TRUST_NEVER ou TRUST_UNDEFINED) ont tous deux été considérés comme un succès.
Les deux cas où un résultat de ' U avaient une signification particulière étaient dans verify_merge_signature() (où cela a provoqué git a die() ) et en format_commit_one() (où il a affecté la sortie de l %G? spécificateur de format).
Je pense qu'il est judicieux de refactoriser le traitement des TRUST_ status de manière à ce que les utilisateurs puissent configurer un niveau de confiance minimum qui soit appliqué globalement, plutôt que d'avoir des parties individuelles de l'infrastructure de l git (par exemple, la fusion) le font eux-mêmes (sauf pour une période de grâce avec la rétrocompatibilité).
Je pense également qu'il est logique de ne pas stocker le niveau de confiance dans le même membre de la structure que le statut de la clé/signature.
Alors que la présence d'un TRUST_ status implique que la signature est bonne (voir le premier paragraphe de l'extrait inclus ci-dessus), pour autant que je sache, l'ordre des lignes d'état de GPG n'est pas bien défini ; il semblerait donc plausible que le niveau de confiance puisse être écrasé par l'état de la clé/signature s'ils étaient stockés dans le même membre du fichier signature_check structure.
Ce patch introduit une nouvelle option de configuration : gpg.minTrustLevel .
Il consolide la vérification du niveau de confiance pour gpg-interface.c et ajoute un nouveau trust_level membre au signature_check structure.
La compatibilité ascendante est maintenue par l'introduction d'un cas particulier dans verify_merge_signature() de sorte que si aucun utilisateur ne peut configurer gpg.minTrustLevel est défini, alors l'ancien comportement de rejet de TRUST_UNDEFINED y TRUST_NEVER est appliquée.
Si, d'un autre côté, gpg.minTrustLevel est définie, alors cette valeur remplace l'ancien comportement.
De même, le %G? le spécificateur de format continuera à afficher ' U ' pour les signatures réalisées avec une clé dont le niveau de confiance est de TRUST_UNDEFINED ou TRUST_NEVER, même si le ' U n'existent plus dans le système result membre de la signature_check structure.
Un nouveau spécificateur de format, %GT est également introduit pour les utilisateurs qui veulent montrer tous les niveaux de confiance possibles pour une signature.
Une autre approche aurait été de simplement abandonner l'exigence du niveau de confiance dans verify_merge_signature() .
Cela aurait également rendu le comportement cohérent avec les autres parties de git qui effectuent la vérification des signatures.
Cependant, l'exigence d'un niveau de confiance minimum pour la signature des clés semble avoir un cas d'utilisation réel.
Par exemple, le système de construction utilisé par le projet Qubes OS analyse actuellement la sortie brute de verify-tag afin d'affirmer un niveau de confiance minimal pour les clés utilisées pour les systèmes d'exploitation. signer les balises git .
El git config gpg page de manuel comprend maintenant :
gpg.minTrustLevel :
Spécifie un niveau de confiance minimum pour la vérification des signatures.
Si cette option n'est pas définie, la vérification de la signature pour les opérations de fusion nécessite une clé ayant au moins la valeur suivante marginal confiance.
D'autres opérations qui effectuent une vérification de signature nécessitent une clé avec au moins undefined confiance.
La définition de cette option remplace le niveau de confiance requis pour toutes les opérations. Valeurs prises en charge, par ordre croissant d'importance :
undefinednevermarginalfullyultimate
Avec Git 2.26 (T1 2020) , " git show " et d'autres donnaient un nom d'objet au format brut dans sa sortie d'erreur, qui a été corrigée pour le donner en hex.
show_one_mergetag : affiche le non-parent sous forme hexagonale.
Quand un mergetag nomme un non-parent, ce qui peut se produire après un son hachage était auparavant imprimé comme une donnée brute.
Imprimez-la plutôt sous forme hexagonale.
Testé avec git -C shallow log --graph --show-signature -n1 plain-shallow après un git clone --depth 1 --no-local . shallow
Avec Git 2.27 (Q2 2020), le code d'interface avec GnuPG a été remanié.
Voir commettre 6794898 , commettre f1e3df3 (04 Mar 2020) par Hans Jerry Illikainen ( illikainen ) .
(fusionné par Junio C Hamano -- gitster -- en commettre fa82be9 , 27 mars 2020)
gpg-interface : préférer check_signature() pour la vérification GPG
Signé par : Hans Jerry Illikainen
Ce commit modifie l'utilisation de verify_signed_buffer() à l'extérieur de gpg-interface.c à utiliser check_signature() à la place.
Il transforme également verify_signed_buffer() en une fonction locale au fichier puisqu'elle n'est maintenant invoquée qu'en interne par check_signature() .
Il y avait auparavant deux fonctions à portée globale utilisées dans différentes parties de Git pour effectuer la vérification de la signature GPG : verify_signed_buffer() y check_signature() .
Maintenant seulement check_signature() est utilisé.
El verify_signed_buffer() ne permet pas de se prémunir contre les signatures en double telles que décrites par Micha Górny .
Au lieu de cela, il assure seulement un code de sortie non erroné de GPG et la présence d'au moins un GOODSIG champ d'état.
Cela contraste avec check_signature() qui renvoie une erreur si plus d'une signature est rencontrée.
Le degré inférieur de vérification permet d'utiliser verify_signed_buffer() problématique si les appelants n'analysent pas et ne valident pas eux-mêmes les différentes parties du message d'état GPG.
Et le traitement de ces messages semble être une tâche qui devrait être réservée à gpg-interface.c avec la fonction check_signature() .
En outre, l'utilisation de verify_signed_buffer() rend difficile l'introduction d'une nouvelle fonctionnalité qui s'appuie sur le contenu des lignes d'état GPG.
Maintenant, toutes les opérations qui font la vérification de la signature partagent un seul point d'entrée pour gpg-interface.c .
Il est ainsi plus facile de propager des fonctionnalités modifiées ou supplémentaires dans la vérification des signatures GPG à toutes les parties de Git, sans avoir de cas limites bizarres qui n'effectuent pas le même degré de vérification. .
Avec Git 2.31 (Q1 2021), les commits et tags signés permettent désormais la vérification des objets, dont les deux noms d'objets (l'un en SHA-1, l'autre en SHA-256) sont tous deux signés.
Voir commit 9b27b49 , commettre 88bce0e , commit 937032e , commettre 482c119 (11 février 2021), et commettre 1fb5cf0 , commettre 83dff3e (18 janvier 2021) par brian m. carlson ( bk2204 ) .
(fusionné par Junio C Hamano -- gitster -- en commit 15af6e6 , 22 février 2021)
commit : ignorer les signatures supplémentaires lors de l'analyse des commits signés
Signé par : brian m. carlson
Lorsque nous créons un commit avec plusieurs signatures, aucune de ces signatures n'inclut l'autre.
Par conséquent, lorsque nous produisons la charge utile qui a été signée afin de pouvoir vérifier le commit, nous devons supprimer toutes les autres signatures, sinon la charge utile sera différente de ce qui a été signé.
Faites-le, et en préparation de la vérification avec de multiples algorithmes, passez l'algorithme que nous voulons vérifier dans le fichier parse_signed_commit .
Brandon propose dans les commentaires a git log alias, qui montre les états clés :
[alias]
lg = "!f() { \
git log --all --color --graph --pretty=format:'%C(bold yellow)<sig>%G?</sig>%C(reset) %C(red)%h%C(reset) -%C(yellow)%d%C(reset) %s %C(green)(%cr) %C(blue)<%an>%C(reset)' | \
sed \
-e 's#<sig>G</sig>#Good#' \
-e 's#<sig>B</sig>#\\nBAD \\nBAD \\nBAD \\nBAD \\nBAD#' \
-e 's#<sig>U</sig>#Unknown#' \
-e 's#<sig>X</sig>#Expired#' \
-e 's#<sig>Y</sig>#Expired Key#' \
-e 's#<sig>R</sig>#Revoked#' \
-e 's#<sig>E</sig>#Missing Key#' \
-e 's#<sig>N</sig>#None#' | \
less -r; \
}; f"
