04 - Signer ses commits Git (GPG et SSH)

Ce que tu vas apprendre

• Pourquoi signer ses commits est nécessaire
• Configurer la signature GPG
• Configurer la signature SSH (plus simple, mon choix recommande)
• Obtenir le badge "Verified" sur GitHub et GitLab

Prerequisites

• 02 - Les clés SSH : si tu veux signer avec SSH
• 03 - GPG : si tu veux signer avec GPG

Le problème : n'importe qui peut etre toi

Essaie ca dans un repo git :

bashgit commit --author="Linus Torvalds <torvalds@linux-foundation.org>" --allow-empty -m "I love Windows"

Ca marche. Git ne vérifié rien. L'auteur d'un commit est juste un champ texte, comme le sujet d'un email. N'importe qui peut écrire n'importe quoi.

Dans un projet perso, c'est anecdotique. Dans un contexte pro avec du CI/CD qui deploie automatiquement, c'est un vrai risque. Un attaquant qui a acces au repo pourrait pousser du code malveillant sous le nom d'un autre développeur. La signature de commit resout ce problème : elle prouve cryptographiquement que le commit vient bien de la personne indiquee.

Option 1 : signature GPG

C'est la méthode historique, supportee par git depuis la version 1.7.9 (2012).

Configuration

bash# Recuperer l'ID de ta cle GPG
gpg --list-secret-keys --keyid-format long
# Note l'ID apres "ed25519/" ou "rsa4096/", par ex: 1234ABCD5678EF90

# Configurer git
git config --global user.signingkey 1234ABCD5678EF90
git config --global commit.gpgsign true
git config --global gpg.program gpg

Le commit.gpgsign true signe automatiquement tous tes commits. Sans ca, il faut ajouter -S a chaque git commit.

Signer et vérifier

bash# Commit signe (automatique si gpgsign = true)
git commit -m "feat: ajout du module auth"

# Verifier les signatures
git log --show-signature -1

Envoyer ta clé sur GitHub

bash# Exporter ta cle publique
gpg --armor --export 1234ABCD5678EF90

Copie le résultat (de -----BEGIN PGP PUBLIC KEY BLOCK----- a -----END PGP PUBLIC KEY BLOCK-----) et colle-le dans GitHub > Settings > SSH and GPG keys > New GPG key.

Meme chose sur GitLab : Preferences > GPG Keys.

Option 2 : signature SSH (mon choix recommande)

Depuis git 2.34 (novembre 2021), tu peux signer tes commits avec une clé SSH. Plus besoin d'installer GPG ni de gerer un trousseau de clés séparé. Si tu as deja une clé SSH (et si tu as lu l'article 02, tu en as une), tu es pret.

Je recommande la signature SSH pour la plupart des développeurs. C'est plus simple, ca utilise les memes clés que ton authentification, et GitHub/GitLab le supportent. Le seul cas ou je conseillerais encore GPG : si tu as besoin de signer autre chose que des commits (des releases, des emails, des fichiers).

Configuration

bash# Dire a git d'utiliser SSH pour signer
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

C'est tout. Trois commandes et c'est fini.

Verification locale

Pour vérifier les signatures SSH localement, tu as besoin d'un fichier allowed_signers :

bash# Creer le fichier
echo "ton.email@exemple.com $(cat ~/.ssh/id_ed25519.pub)" > ~/.ssh/allowed_signers

# Dire a git ou le trouver
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers

Maintenant git log --show-signature fonctionne aussi avec les clés SSH.

Envoyer ta clé sur GitHub

Va dans GitHub > Settings > SSH and GPG keys > New SSH key. Type : Signing Key (pas Authentication). Colle le contenu de ~/.ssh/id_ed25519.pub.

Tu peux utiliser la meme clé pour l'authentification et la signature, ou des clés différentes. Perso, j'utilise la meme. Ca fait un truc de moins a gerer.

Sur GitLab, c'est dans Preferences > SSH Keys, et tu coches "Signing" lors de l'ajout.

Le badge "Verified"

Une fois ta clé enregistree sur GitHub ou GitLab, tes commits signes affichent un badge vert "Verified" dans l'interface web. Ca prouve que :

1. Le commit a ete signe avec une clé valide
2. Cette clé est associee au compte de l'auteur

Les commits non signes n'affichent rien. Tu peux meme configurer un repo pour rejeter les commits non signes (branch protection rules sur GitHub, push rules sur GitLab).

Signer les tags aussi

Les tags de release meritent aussi d'etre signes :

bash# Tag signe
git tag -s v1.0.0 -m "Release 1.0.0"

# Verifier un tag
git tag -v v1.0.0

Si tu publies des packages (npm, crates.io, PyPI), un tag signe donne une garantie supplementaire a tes utilisateurs.

Le setup complet en 2 minutes

Voici le script pour tout configurer d'un coup avec la signature SSH :

bash# Si tu n'as pas encore de cle SSH
ssh-keygen -t ed25519 -C "ton.email@exemple.com"

# Configuration git
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# Verification locale
echo "ton.email@exemple.com $(cat ~/.ssh/id_ed25519.pub)" > ~/.ssh/allowed_signers
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers

Apres ca, chaque git commit et git tag sera signe automatiquement. N'oublie pas d'ajouter ta clé publique sur GitHub/GitLab en tant que "Signing Key".

Mon avis trancher

Pour un développeur fullstack en 2026, la signature SSH est le choix par défaut. GPG, c'est bien, mais c'est un outil complexe avec un ecosysteme complique (keyservers, trust model, sous-clés...). Pour juste signer des commits, c'est overkill.

Si tu travailles dans la sécurité ou que tu maintiens un projet open source majeur, la signature GPG a du sens. Pour le quotidien d'un dev qui veut un badge "Verified" et une meilleure hygiene, SSH suffit largement.

Prochaine étape : comprendre comment TLS protégé le web. TLS, HTTPS et certificats.

Navigation : Precedent : 03 - GPG | Suivant : 05 - TLS et certificats

Sources

• Git Documentation - Signing Your Work par git-scm.com
• GitHub Docs - Signing commits par GitHub
• GitLab Docs - Sign commits with SSH keys par GitLab
• Git 2.34 Release Notes par Git Project

Retrouve d'autres articles techniques sur paltemps.fr.