Tout le monde peut commit en votre nom

Essaie ça, là, maintenant :

git config user.name "Linus Torvalds"
git config user.email "torvalds@linux-foundation.org"
git commit --allow-empty -m "ceci n'est pas vraiment de moi"

Rien ne t’en empêche. Git te fait confiance sur parole : le champ author d’un commit, c’est juste du texte que tu peux remplir avec ce que tu veux. Si tu pushes ça sur un repo où t’as les droits, GitHub va afficher le commit avec le nom et la photo de Linus, comme s’il l’avait écrit lui-même.

La seule différence visible ? L’absence du badge Verified à côté du commit. Et à moins de le chercher activement, personne ne le remarque.

Cet article est une adaptation de celui de Nick Taylor, que je trouvais trop utile pour ne pas le remettre en français sur mon blog. Merci à lui pour le sujet.

Pourquoi c’est un problème

Sur le papier ça semble anecdotique, mais les cas d’usage malveillants sont bien réels :

Usurpation dans l’open source : quelqu’un commit du code vérolé en se faisant passer pour un mainteneur de confiance.
Sabotage en entreprise : un collègue (ou un attaquant ayant accès au repo) fait passer un bug ou une backdoor pour ton travail.
Conformité réglementaire : dans certains secteurs (finance, santé), il faut pouvoir prouver que le code vient bien de la personne indiquée.
Attaque de la chaîne d’approvisionnement : un commit falsifié dans une dépendance peut se propager à tous les projets qui l’utilisent.

La solution : signer tes commits cryptographiquement, pour que Git (et GitHub) puisse prouver que c’est vraiment toi qui as écrit ce code, et pas juste quelqu’un qui connaît ton git config.

Deux façons de le faire : GPG, la méthode historique, ou SSH, plus simple si t’as déjà une clé SSH qui traîne.

Option 1 : signer avec GPG

GPG (GNU Privacy Guard) est une implémentation libre du standard OpenPGP, qui sert à chiffrer et signer des données. C’est la méthode la plus ancienne et la plus universelle. (Encore un acronyme de plus dans le jargon dev, j’en parlais ici.)

Installer GPG

macOS : GPG Suite, qui inclut une interface graphique (GPG Keychain) en plus des outils en ligne de commande.
Linux : gpg est généralement déjà installé. Sinon, sudo apt install gnupg (Debian/Ubuntu) ou l’équivalent de ta distro.
Windows : Gpg4win, ou directement les binaires officiels sur gnupg.org/download.

Générer une clé

En ligne de commande, ça donne :

gpg --full-generate-key

Réponds aux questions :

Type de clé : RSA and RSA (par défaut)
Taille : 4096 bits minimum
Validité : 1 an, c’est un bon compromis (tu renouvelles facilement, et une clé compromise a une durée de vie limitée)
Nom et email : le même email que celui vérifié sur ton compte GitHub, sinon la signature n’apparaîtra jamais comme “Verified”
Une passphrase solide pour protéger la clé privée

Sauvegarder la clé privée

C’est l’étape que tout le monde saute, et que tout le monde regrette un jour. Ta passphrase protège ta clé privée, mais ce n’est pas une sauvegarde. Si tu perds le fichier de la clé, la passphrase la plus solide du monde ne te la rendra pas.

gpg --export-secret-keys --armor TON_EMAIL@exemple.com > private-key.asc

Planque ce fichier dans un gestionnaire de mots de passe (1Password, Bitwarden…) ou sur un support chiffré. Jamais en clair sur un cloud public.

Récupérer et ajouter la clé publique sur GitHub

gpg --list-secret-keys --keyid-format=long

Repère l’identifiant après sec rsa4096/, puis exporte la clé publique :

gpg --armor --export TON_ID_DE_CLE

Copie tout le bloc, du -----BEGIN PGP PUBLIC KEY BLOCK----- au -----END PGP PUBLIC KEY BLOCK-----, et colle-le dans GitHub → Settings → SSH and GPG keys → New GPG key.

Configurer Git

git config --global user.signingkey TON_ID_DE_CLE
git config --global commit.gpgsign true
git config --global gpg.program $(which gpg)

Vérifier que ça marche

git commit --allow-empty -m "Test de signature GPG"
git log --show-signature -1

Tu dois voir Good signature dans la sortie. Sur GitHub, le commit affiche maintenant le badge Verified.

Option 2 : signer avec SSH

Depuis 2022, GitHub accepte aussi les signatures SSH. Si t’as déjà une clé SSH pour te connecter à GitHub, c’est nettement plus rapide à mettre en place que GPG, et t’évites de jongler avec un trousseau supplémentaire.

Configurer Git pour signer en SSH

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

Remplace le chemin par celui de ta clé publique existante (id_ed25519.pub, id_rsa.pub, etc.).

Déclarer la clé comme clé de signature sur GitHub

Une clé SSH peut servir à deux choses sur GitHub : s’authentifier, ou signer. Ce n’est pas automatique.

Va dans GitHub → Settings → SSH and GPG keys → New SSH key, colle ta clé publique, et choisis bien Signing Key comme type (pas Authentication Key, sinon la vérification échouera). Tu peux tout à fait ajouter la même clé deux fois, une fois pour chaque usage.

Vérifier

git commit --allow-empty -m "Test de signature SSH"
git log --show-signature -1

Même résultat attendu : Good "git" signature, et le badge Verified sur GitHub.

Que choisir ?

	GPG	SSH
Mise en place	Plus longue, outil dédié	Rapide si tu as déjà une clé SSH
Écosystème	Standard historique, largement supporté	Supporté par GitHub/GitLab depuis peu
Gestion des clés	Trousseau séparé à sauvegarder	Réutilise ta clé SSH existante
Cas d’usage	Environnements réglementés, habitudes historiques	Setup perso, rapidité

Si tu pars de zéro et que t’as juste besoin d’un badge Verified honnête, SSH est le choix le plus simple. GPG reste pertinent si ton organisation l’exige déjà, ou si tu veux aussi signer/chiffrer d’autres données que des commits.

Problèmes fréquents

gpg failed to sign the data : le chemin vers gpg.program est incorrect, ou l’ID de clé configuré n’existe pas. Vérifie avec gpg --list-secret-keys.
No secret key : la clé n’est pas dans le trousseau de la machine sur laquelle tu commit. Une clé générée sur ton laptop ne signera rien sur ton serveur.
Commit non vérifié malgré une signature valide : l’email du commit ne correspond à aucun email vérifié sur ton compte GitHub. Vérifie git config user.email.

Renouveler sa clé GPG

Une clé qui expire, ça arrive (volontairement, pour la sécurité). Pour prolonger sans tout recréer :

gpg --edit-key TON_ID_DE_CLE
gpg> expire
gpg> save

Aucune action à faire côté GitHub après ça : la clé publique déjà enregistrée reste valide.

Conclusion

La signature de commits n’est pas (encore) obligatoire partout, mais la tendance va clairement dans ce sens, particulièrement dans l’open source et les secteurs réglementés. Un peu comme HTTPS il y a quinze ans : ce qui était optionnel devient la norme.

Quinze minutes pour configurer une signature SSH ou GPG, c’est peu cher payé pour ne plus jamais avoir à prouver que “non, ce commit chelou, c’est pas moi”.

Thanks again to Nick Taylor for the original article this one is based on.