Signer des commits et des tags avec une clé SSH ou GPG

Objectif

Associer une signature vérifiable aux commits et aux tags de version, afin qu'une personne qui relit ou qu'un build puisse vérifier qu'un changement provient du détenteur d'une clé connue, et pas seulement de quelqu'un qui a tapé un nom dans user.email.

Prérequis

Git avec la prise en charge de gpg.format (la documentation de git-config répertorie les valeurs openpgp (par défaut), x509 et ssh). Pour la signature SSH : une paire de clés SSH et ssh-keygen d'OpenSSH, qui effectue la signature. Pour GPG : une paire de clés avec un identifiant de clé. Un endroit où publier les clés publiques, comme les paramètres de compte de la plateforme d'hébergement.

Étapes

1. Choisir le format. SSH réutilise la clé que les personnes qui développent possèdent déjà et ne nécessite aucun serveur de clés ; GPG porte un modèle de toile de confiance et une expiration. Définir git config --global gpg.format ssh (ou laisser la valeur par défaut pour GPG).
2. Nommer la clé : git config --global user.signingKey ~/.ssh/id_ed25519.pub pour SSH (le guide de GitHub montre les mêmes commandes), ou l'identifiant de clé GPG.
3. Activer la signature par défaut : git config --global commit.gpgSign true et git config --global tag.gpgSign true. La documentation note que les rebase signent alors de nombreux commits, donc utiliser un agent pour éviter des invites de phrase secrète répétées.
4. Vérifier localement. Avec SSH, créer un fichier allowed-signers avec des lignes de la forme principal ssh-ed25519 AAAA... et pointer gpg.ssh.allowedSignersFile vers celui-ci ; la documentation indique que SSH n'a pas de niveaux de confiance : une clé répertoriée dans ce fichier reçoit le niveau de confiance « fully », sinon git verify-commit et git verify-tag échouent, si bien que ce fichier constitue à lui seul la décision de confiance. Exécuter ensuite git verify-commit HEAD et git verify-tag v1.2.0, ou git log --show-signature.
5. Téléverser la clé publique sur la plateforme d'hébergement en tant que clé de signature, afin que son interface marque les commits comme vérifiés.
6. Signer les tags de version avec git tag -s v1.2.0 -m "..." ; seuls les objets de tag annotés peuvent porter une signature.
7. Pour la rotation des clés, conserver l'ancienne clé publique dans le fichier allowed-signers avec les options valid-after et valid-before (OpenSSH 8.8 ou plus récent, selon la documentation) ; Git accepte alors les signatures faites pendant que la clé était valide. Les clés révoquées vont dans gpg.ssh.revocationFile, une KRL ou une simple liste de clés dont les entrées sont toujours signalées invalides.

Résultat attendu

git verify-commit rapporte une bonne signature pour les commits signés, la plateforme les affiche comme vérifiés, et un commit non signé ou mal signé est visible comme tel en relecture et peut être rejeté par les règles de branche.

Limites et base de vérification

Une signature prouve la possession d'une clé au moment de la signature, pas que le changement est correct ni que le détenteur de la clé est bien la personne que le nom indique. Les fusions en squash ou en rebase effectuées par la plateforme d'hébergement créent de nouveaux commits qui ne portent aucune signature, ou celle de la plateforme elle-même. Le comportement suit la documentation citée ; aucune mesure d'adoption ni d'effort n'est revendiquée.