infra / git-github
Signature des commits avec GPG/SSH (niveau expert)
Explication
Ce que vous allez apprendre
- Comprendre pourquoi le champ auteur d'un commit n'est qu'une déclaration, pas une preuve
- Générer une clé GPG ou réutiliser une clé SSH existante pour signer des commits
- Configurer Git pour signer automatiquement chaque commit (
commit.gpgsign true) - Vérifier la signature d'un commit ou d'un tag avec
git verify-commit/verify-tag - Imposer les commits signés au niveau d'un dépôt via une règle de branche protégée
Dans quel contexte ?
Une organisation qui gère des paiements sur boutique-api doit prouver, lors d'un audit de sécurité, que chaque commit déployé en production provient bien d'un développeur identifié et autorisé, et non d'une identité usurpée en configurant simplement un faux nom local. La signature cryptographique des commits, combinée à une règle GitHub "Require signed commits", répond précisément à cette exigence.
Un problème que le nom d'auteur ne résout pas
D'abord, depuis la toute première leçon, chaque commit porte un nom et un email d'auteur. Mais rien n'empêche techniquement quelqu'un de configurer n'importe quel nom sur sa propre machine et de committer en se faisant passer pour toi.
Ce que ce champ ne prouve pas
Le champ auteur d'un commit est une simple déclaration, pas une preuve.
La solution : une preuve mathématique
La signature cryptographique des commits répond à ce problème de confiance : elle prouve mathématiquement qu'un commit a bien été créé par la personne qui possède une clé privée précise.
Une preuve pratiquement impossible à falsifier
C'est une preuve qu'il est pratiquement impossible de falsifier, contrairement à une simple déclaration de nom.
Le principe de la clé publique/privée
L'idée centrale est simple : tu génères une paire de clés, une privée que tu gardes absolument secrète sur ta machine, et une publique que tu partages sans risque, en la déclarant sur GitHub.
Ce que cette paire de clés permet
Chaque commit signé porte la preuve mathématique qu'il a été créé avec ta clé privée, vérifiable par n'importe qui possédant ta clé publique, d'où le badge "Verified" qui apparaît sur GitHub.
| Méthode de signature | Clé réutilisée | Complexité de configuration |
|---|---|---|
| GPG | Clé GPG dédiée | Plus élevée (historique) |
| SSH (Git 2.34+) | Clé SSH déjà utilisée pour l'authentification | Plus simple |
Prérequis
Cette leçon suppose que tu as déjà généré une clé SSH pour t'authentifier auprès de GitHub (leçon sur le push). Si c'est le cas, signer avec SSH ne demande presque aucune configuration supplémentaire.
Deux chemins vers le même résultat
Historiquement, la signature de commits utilisait exclusivement GPG, un système plus ancien et parfois perçu comme complexe à configurer.
Une alternative plus simple aujourd'hui
Les versions récentes de Git permettent une alternative bien plus simple pour qui a déjà une clé SSH, souvent déjà générée pour s'authentifier auprès de GitHub, comme vu dans la leçon sur le push : réutiliser cette même infrastructure pour signer.
Rendre la règle incontournable, pas juste conseillée
Enfin, une organisation soucieuse de sécurité ne se contente généralement pas de "conseiller" la signature : elle l'impose techniquement via une règle de protection de branche sur GitHub, qui refuse purement et simplement tout commit non signé sur les branches sensibles.
Bonne pratique
Active git config --global commit.gpgsign true dès que tu configures la signature, plutôt que de te fier à ta mémoire pour ajouter -S à chaque commit. Combine-la avec une règle "Require signed commits" sur la branche main pour rendre la protection réellement incontournable, pas seulement recommandée.
Ce cours touche ici à sa fin : tu es maintenant capable de gérer un historique Git propre, de collaborer efficacement sur GitHub, et de sécuriser tes commits jusqu'au niveau expert.
Commandes & code
Signer ses commits (GPG / SSH)
La signature prouve cryptographiquement qu'un commit vient bien de son auteur déclaré, pas d'une identité usurpée.
# Générer une clé GPG dédiée
gpg --full-generate-key # choisir RSA 4096, associer l'email du compte GitHub
gpg --list-secret-keys --keyid-format=long
# sec rsa4096/3AA5C34371567BD2 2026-01-10 [SC]
# Exporter la clé publique et l'ajouter à GitHub (Settings > SSH and GPG keys)
gpg --armor --export 3AA5C34371567BD2# Configurer Git pour utiliser cette clé et signer par défaut
git config --global user.signingkey 3AA5C34371567BD2
git config --global commit.gpgsign true
git config --global tag.gpgSign true
git commit -m "feat: add refund workflow" # signé automatiquement désormais
git commit -S -m "signed manually just once" # forcer la signature ponctuellement# Alternative plus simple depuis Git 2.34+ : signer avec une clé SSH plutôt que GPG
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
# Déclarer la même clé publique comme "signing key" dans GitHub (en plus de la clé d'authentification)# Vérifier la signature d'un commit
git log --show-signature -1
git verify-commit HEAD
git verify-tag v1.0.0# Sur GitHub : forcer les commits signés via une règle de branche protégée
# Settings > Branches > Branch protection rules
# [x] Require signed commits
# [x] Require a pull request before merging
# [x] Require status checks to pass before merging
# [x] Require linear history (empêche les merge commits, force rebase/squash)# Vérifier en CI qu'un commit non signé n'entre jamais sur main (défense en profondeur)
git log origin/main..HEAD --format='%H %G?' | grep -v ' [GU]$' && {
echo "Commit(s) non signé(s) détecté(s)."; exit 1;
}Résumé
- La signature (GPG ou SSH) prouve l'authenticité de l'auteur, "Verified" apparaît sur GitHub.
gpg.format sshpermet de signer avec une clé SSH existante, plus simple que GPG classique.commit.gpgsign truesigne automatiquement chaque commit sans y penser.- Les règles de branche protégée (
Require signed commits) imposent la signature au niveau du dépôt.
Exercices pratiques
Mission : prouver l'authenticité des commits pour un audit
Objectif : Configurer la signature automatique des commits et expliquer pourquoi le champ auteur seul ne suffit pas comme preuve de sécurité.
Contexte
Une organisation qui gère des paiements sur boutique-api doit prouver lors d'un audit que chaque commit déployé en production provient bien d'un développeur identifié, et non d'une identité usurpée en configurant simplement un faux user.name local.