À propos de la vérification des signatures de commit
Vous pouvez signer des commits et des étiquettes localement pour renforcer la confiance des autres utilisateurs quant à l’origine d’une modification que vous avez apportée. Si une validation ou une balise a une signature GPG, SSH ou S/MIME vérifiable par chiffrement, GitHub marque la validation ou la balise « Vérifié » ou « Partiellement vérifié ».
Pour la plupart des utilisateurs individuels, GPG ou SSH est le meilleur choix pour la signature de commits. Les signatures S/MIME sont généralement requises dans le contexte d’une organisation de plus grande taille. Les signatures SSH sont les plus simples à générer. Vous pouvez même charger votre clé d’authentification existante pour GitHub l’utiliser également comme clé de signature. La génération d’une clé de signature GPG est plus impliquée que la génération d’une clé SSH, mais GPG a des fonctionnalités que SSH n’a pas. Une clé GPG peut expirer ou être révoquée lorsqu’elle n’est plus utilisée. La signature GPG peut inclure les informations relatives à son expiration ou à sa révocation.
Les commits et étiquettes ont les états de vérification suivants selon que vous avez activé ou non le mode vigilant. Par défaut, le mode vigilant n’est pas activé. Pour plus d’informations sur l’activation du mode vigilant, consultez Affichage des états de vérification pour tous vos commits.
La signature d’un commit diffère de l’approbation d’un commit. Pour plus d’informations sur la signature des commits, consultez Gestion de la stratégie de validation de commits pour votre dépôt.
États par défaut
| Statut | Description |
|---|---|
| Vérifiée | Le commit est signé et la signature a été vérifiée avec succès. |
| Non vérifié | Le commit est signé, mais la signature n’a pas pu être vérifiée. |
| Pas d’état de vérification | Le commit n’est pas signé. |
Vérification persistente des signatures de commit
Quel que soit le choix de signature - GPG, SSH ou S/MIME - une fois qu’une signature de validation est vérifiée, elle reste vérifiée dans le réseau de son référentiel. Consultez « Compréhension des connexions entre dépôts ».
Lorsqu’une signature de commit est vérifiée au moment où le commit est envoyé vers GitHub, un enregistrement de vérification est conservé avec le commit. Cet enregistrement ne peut pas être modifié et persiste afin que les signatures restent vérifiées au fil du temps, même si les clés de signature sont pivotées, révoquées ou si les contributeurs quittent l’organisation.
L’enregistrement de vérification inclut un marquage d’horodatage lorsque la vérification a été effectuée. Cet enregistrement persistant garantit un état vérifié cohérent, fournissant un historique stable des contributions au sein du référentiel. Vous pouvez afficher cet horodatage en pointant sur le badge « Vérifié » ou GitHub en accédant à la validation via l’API REST, qui inclut un verified_at champ. Consultez « Points de terminaison d’API REST pour les commits ».
La vérification de la signature de validation persistante s’applique aux nouvelles validations envoyées à GitHub. Pour les validations qui précèdent cette fonctionnalité, un enregistrement persistant est créé la prochaine fois que la signature de la validation est vérifiée GitHub, ce qui permet de s’assurer que les états vérifiés restent stables et fiables dans l’historique du référentiel.
Les enregistrements persistent même après la révocation et l’expiration
La vérification persistante de la signature de commit reflète l’état vérifié d’un commit au moment de la vérification. Cela signifie que si une clé de signature est ultérieurement révoquée, expirée ou modifiée d'une autre manière, les livraisons précédemment vérifiées conservent leur statut vérifié sur la base de l'enregistrement créé lors de la vérification initiale. GitHub ne revérifiera pas les commits précédemment signés ni n’ajustera rétroactivement leur statut de vérification en réponse aux modifications apportées à l’état de la clé. Les organisations peuvent avoir besoin de gérer directement les états des clés afin de s’aligner sur leurs stratégies de sécurité, en particulier si une rotation ou une révocation fréquente des clés est planifiée.
L’enregistrement de vérification est limité à son réseau de dépôts
L’enregistrement de vérification est persistant sur le réseau du référentiel, ce qui signifie que si la même validation est envoyée à nouveau au même référentiel ou à l’une de ses duplications, l’enregistrement de vérification existant est réutilisé. Cela permet GitHub de maintenir un état vérifié cohérent entre les référentiels associés sans vérifier à nouveau la validation chaque fois qu’elle apparaît dans le réseau. Cette persistance renforce une vue unifiée et fiable de l’authenticité de la validation sur toutes les instances de la validation au sein du réseau de référentiel.
Vérification de signature pour le rebasage et la fusion
Lorsque vous utilisez l’option Rebaser et fusionner sur une demande de tirage, il est important de noter que les validations de la branche principale sont ajoutées à la branche de base sans vérification de la signature de validation. Lorsque vous utilisez cette option, GitHub créent une validation modifiée à l’aide des données et du contenu de la validation d’origine. Cela signifie que GitHub n’a pas vraiment créé cette validation et ne peut donc pas la signer en tant qu’utilisateur de système générique. GitHub n’a pas accès aux clés de signature privées du validateur. Il ne peut donc pas signer la validation au nom de l’utilisateur.
Une solution de contournement consiste à rebaser et fusionner localement, puis à envoyer les modifications à la branche de base de la demande de tirage.
Pour plus d’informations, consultez « À propos des méthodes de fusion sur GitHub ».
Statuts avec mode vigilant activé
| Statut | Description |
|---|---|
| Verified | La validation est signée, la signature a été vérifiée avec succès et le validateur est le seul auteur qui a activé le mode vigilant. |
| Partiellement vérifié | La validation est signée et la signature a été vérifiée avec succès, mais l’auteur de la validation : a) n’est pas le validateur et b) a activé le mode vigilant. Dans ce cas, la signature de validation ne garantit pas le consentement de l’auteur. La validation n’est donc que partiellement vérifiée. |
| Non vérifié | L’une des affirmations suivantes est vraie : - La validation est signée, mais la signature n’a pas pu être vérifiée. - La validation n’est pas signée et le validateur a activé le mode vigilant. - La validation n’est pas signée et un auteur a activé le mode vigilant. |
Les administrateurs de dépôt peuvent appliquer la signature de commit nécessaire sur une branche pour bloquer tous les commits qui ne sont pas signés et vérifiés. Pour plus d’informations, consultez « À propos des branches protégées ».
Vous pouvez vérifier l'état de vérification de vos commits ou tags signés sur GitHub et voir pourquoi vos signatures de commit ne sont pas vérifiées. Pour plus d’informations, consultez « Contrôle de l’état de la vérification de la signature du commit et de l’étiquette ».
GitHub utilise automatiquement GPG pour signer les validations que vous effectuez à l’aide de l’interface web. Les commits signés par GitHub auront le statut « Vérifié ». Vous pouvez vérifier la signature localement à l’aide de la clé publique disponible à l’adresse https://github.com/web-flow.gpg.
Vous pouvez facultativement choisir que GitHub signe avec GPG les commits que vous effectuez dans GitHub Codespaces. Pour plus d’informations sur l’activation de la vérification GPG pour vos espaces de code, consultez Gestion de la vérification GPG pour les espaces de code GitHub.
Vérification des signatures de commit GPG
Vous pouvez utiliser GPG pour signer des commits avec une clé GPG que vous générez vous-même.
GitHub utilise des bibliothèques OpenPGP pour confirmer que vos validations et balises signées localement sont vérifiables par chiffrement par rapport à une clé publique que vous avez ajoutée à votre compte sur GitHub.com.
Pour signer des commits à l’aide de GPG et faire vérifier ces commits sur GitHub, procédez comme suit :
- Vérifier les clés GPG existantes
- Générer une nouvelle clé GPG
- Addez une clé GPG à votre compte GitHub
- Informer Git de l’utilisation de votre clé de signature
- Signer les commits
- Signer les étiquettes
Vérification des signatures de commit SSH
Vous pouvez utiliser SSH pour signer des commits avec une clé SSH que vous générez vous-même. Pour plus d’informations, consultez la documentation de référence de Git pour user.Signingkey. Si vous utilisez déjà une clé SSH pour vous authentifier avec GitHub, vous pouvez également charger cette même clé pour une utilisation comme clé de signature. Il n’existe aucune limite quant au nombre de clés de signature que vous pouvez ajouter à votre compte.
GitHub utilise ssh_data, une bibliothèque ruby open source, pour confirmer que vos validations et balises signées localement sont vérifiables par chiffrement par rapport à une clé publique que vous avez ajoutée à votre compte sur GitHub.com.
Remarque
La vérification de signature SSH est disponible dans Git 2.34 ou version ultérieure. Pour mettre à jour votre version de Git, consultez le site web Git.
Pour signer des validations à l’aide de SSH et vérifier ces validations GitHub, procédez comme suit :
- Rechercher les clés SSH existantes
- Générer une nouvelle clé SSH
- Addez une clé de signature SSH à votre compte GitHub
- Informer Git de l’utilisation de votre clé de signature
- Signer les commits
- Signer les étiquettes
Vérification des signatures de commit S/MIME
Vous pouvez utiliser S/MIME pour signer des commits avec une clé X.509 émise par votre organisation.
GitHub utilise le package Debian ca-certificates, le même magasin d’approbation utilisé par les navigateurs Mozilla, pour confirmer que vos validations et balises signées localement sont vérifiables par chiffrement sur une clé publique dans un certificat racine approuvé.
Remarque
La vérification de signature S/MIME est disponible dans Git 2.19 ou version ultérieure. Pour mettre à jour votre version de Git, consultez le site web Git.
Pour signer des commits à l’aide de S/MIME et faire vérifier ces commits sur GitHub, procédez comme suit :
Vous n’avez pas besoin de charger votre clé publique sur GitHub.
Vérification de signature pour les bots
Les organisations et GitHub Apps qui exigent la signature des commits peuvent utiliser des bots pour signer des commits. Si une validation ou une balise a une signature de bot qui est vérifiable par chiffrement, GitHub marque la validation ou la balise comme vérifiée.
La vérification de signature pour les bots ne fonctionne que si la requête est vérifiée et authentifiée en tant que GitHub App ou bot, et qu’elle ne contient aucune information personnalisée sur l’auteur, aucune information personnalisée sur le validateur, ni aucune information de signature personnalisée, par exemple via l’API Commits.