À 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. GitHub Enterprise Cloud affiche les commits signés avec une telle clé comme « Vérifiés », sauf si la clé a été marquée comme compromise. Les clés SSH n’ont pas cette capacité.
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é. |
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 :
- Vérifier les clés GPG existantes
- Générer une nouvelle clé GPG
- Ajouter 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 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.
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 commits avec SSH et les faire vérifier sur GitHub Enterprise Cloud, effectuez les étapes suivantes :
- Rechercher les clés SSH existantes
- Générer une nouvelle clé SSH
- Ajouter 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 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é.
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 avec S/MIME et les faire vérifier sur GitHub Enterprise Cloud, effectuez les étapes suivantes :
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).