À 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 Server marque le commit ou l’étiquette comme « Vérifié ».

Capture d’écran d’un commit dans la liste de commits d’un dépôt. « Vérifié » est mis en évidence avec un encadré orange.

Si un commit ou une étiquette a une signature qui ne peut pas être vérifié, GitHub Enterprise Server marque le commit ou l’étiquette comme « Non 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 Server 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 Server 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é.

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

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 Server 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 ».

Si un administrateur de site a activé la signature de commit web, GitHub Enterprise Server utilise automatiquement GPG pour signer les commits que vous effectuez à l’aide de l’interface web. Les commits signés par GitHub Enterprise Server ont un état vérifié. Vous pouvez vérifier la signature localement à l’aide de la clé publique disponible à l’adresse https://HOSTNAME/web-flow.gpg. Pour plus d’informations, consultez « Configuration de la signature de validation web ».

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 Server 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 votre instance GitHub Enterprise Server.

Pour signer des commits avec GPG et les faire vérifier sur GitHub Enterprise Server, effectuez les étapes suivantes :

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 Server, 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 Server 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 votre instance GitHub Enterprise Server.

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 Server, effectuez les étapes suivantes :

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 Server 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 Server, effectuez les étapes suivantes :

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

Pour aller plus loin

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

À propos de la vérification des signatures de commit

Dans cet article