À propos de la vérification des signatures de commit

À 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 un commit ou une étiquette a une signature GPG, SSH ou S/MIME vérifiable par chiffrement, GitHub Enterprise Cloud marque le commit ou l’étiquette comme « 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 sur GitHub Enterprise Cloud pour 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 l’approbation de commits, consultez Gestion de la stratégie de validation de commits pour votre dépôt.

États par défaut

Statut	Description
Verified	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é.

À propos de la vérification 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 validation est vérifiée après avoir été transférée vers GitHub Enterprise Cloud, un enregistrement de vérification est stocké avec la validation. 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é » sur GitHub Enterprise Cloud ou en accédant à la validation via l’API REST, qui inclut un champ verified_at . 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 Enterprise Cloud. Pour toutes les modifications antérieures à cette fonctionnalité, un enregistrement persistant sera créé la prochaine fois que la signature de la modification sera vérifiée sur GitHub Enterprise Cloud, ce qui permettra de s'assurer que les statuts vérifiés restent stables et fiables tout au long de l'historique du référentiel.

Les enregistrements persistent même après la révocation et l’expiration

La vérification de la signature de validation persistante reflète l’état vérifié d’une validation 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 Enterprise Cloud ne revérifiera pas les commits précédemment signés ou n'ajustera pas rétroactivement leur statut de vérification en réponse à des changements dans l'état de la clé. Les organisations peuvent avoir besoin de gérer directement les états clés pour s’aligner sur leurs stratégies de sécurité, en particulier si la rotation ou la révocation fréquente des clés est planifiée.

L’enregistrement de vérification est limité à son réseau de référentiel

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 Enterprise Cloud 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 ».

États 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 consulter l’état de vérification de vos étiquettes ou commits signés sur GitHub Enterprise Cloud et voir la raison pour laquelle vos signatures de commit ne son 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 commits que vous effectuez à l’aide de l’interface web. Les commits signés par GitHub ont un état 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 également déterminer que GPG GitHub signe les commits que vous effectuez dans GitHub Codespaces. Pour plus d’informations sur l’activation de la vérification GPG pour vos codespaces, consultez Gestion de la vérification GPG pour GitHub Codespaces.

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 Enterprise Cloud utilise des bibliothèques OpenPGP pour vérifier que vos commits et étiquettes signés 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 avec GPG et les faire vérifier sur GitHub Enterprise Cloud, effectuez les étapes suivantes :

1. Vérifier les clés GPG existantes
2. Générer une nouvelle clé GPG
3. Ajouter une clé GPG à votre compte GitHub
4. Informer Git de l’utilisation de votre clé de signature
5. Signer les commits
6. 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 auprès de GitHub Enterprise Cloud, vous pouvez également charger à nouveau cette même clé pour l’utiliser comme clé de signature. Il n’existe aucune limite quant au nombre de clés de signature que vous pouvez ajouter à votre compte.

GitHub Enterprise Cloud utilise ssh_data, une bibliothèque Ruby open source, pour vérifier que vos commits et étiquettes signés 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 avec SSH et les faire vérifier sur GitHub Enterprise Cloud, effectuez les étapes suivantes :

1. Rechercher les clés SSH existantes
2. Générer une nouvelle clé SSH
3. Ajouter une clé de signature SSH à votre compte GitHub
4. Informer Git de l’utilisation de votre clé de signature
5. Signer les commits
6. 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 Enterprise Cloud utilise le paquet ca-certificates Debian (magasin de confiance utilisé par les navigateurs Mozilla) pour vérifier que vos commits et étiquettes signés localement sont vérifiables par chiffrement par rapport à une clé publique dans un certificat racine approuvé.

Pour signer des commits avec S/MIME et les faire vérifier sur GitHub Enterprise Cloud, effectuez les étapes suivantes :

1. Informer Git de l’utilisation de votre clé de signature
2. Signer les commits
3. Signer les étiquettes

Vous n’avez pas besoin de charger votre clé publique sur GitHub Enterprise Cloud.

Vérification de signature pour les bots

Les organisations et GitHub Apps qui nécessitent la signature de commit peuvent utiliser des bots pour signer les commits. Si un commit ou une étiquette a une signature de bot vérifiable par chiffrement, GitHub Enterprise Cloud marque le commit ou l’étiquette comme vérifié.

La vérification de signature pour les bots fonctionne uniquement si la demande est vérifiée et authentifiée comme GitHub App ou bot et ne contient aucune information d’auteur personnalisée, aucune information de commiteur personnalisée et aucune information de signature personnalisée (API Commits, par exemple).

Pour aller plus loin

• Signature de commits
• Signature d’étiquettes
• Résolution des problèmes de vérification de signature de commit