Voici un petit article simple sur comment activer la signature de commits avec Git et PGP.

Ca veut dire quoi “signer ses commits” ?

Dans sa documentation, les auteurs de Git le disent eux-même : “Git est cryptographiquement sûr, mais pas infaillible”. Lorsqu’on récupère des objets en provenance d’Internet, une bonne pratique est de vérifier la signature cryptographique de ceux-ci. Souvent proposée sous la forme d’un hash ou checksum à comparer, cette signature est une valeur permettant de certifier que l’objet récupéré n’a pas été altéré en chemin (attaque man in the middle, réécriture des binaires à la volée, corruption pas d’bol, etc).

Exemple avec le téléchargement de Fedora. Le site de la distribution propose de vérifier l’intégrité de l’image obtenue en comparant sa signature. En récupérant le fichier CHECKSUM associé à l’ISO, gpg est capable de nous dire si celui-ci correspond bien à ce qui est proposé au téléchargement par Fedora.

$ ll Fedora-Workstation-*
Fedora-Workstation-33-1.2-x86_64-CHECKSUM
Fedora-Workstation-Live-x86_64-33-1.2.iso

$ gpg --verify-files *-CHECKSUM
gpg: Signature faite le ven. 23 oct. 2020 17:09:17 CEST
gpg:                avec la clef RSA 963A2BEB02009608FE67EA4249FD77499570FF31
gpg: Bonne signature de « Fedora (33) <fedora-33-primary@fedoraproject.org> » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:             Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 963A 2BEB 0200 9608 FE67  EA42 49FD 7749 9570 FF31

$ sha256sum -c *-CHECKSUM
Fedora-Workstation-Live-x86_64-33-1.2.iso: Réussi

Ici, GPG indique que le fichier ISO reçu est conforme à la signature calculée avec la clé publique de Fedora. Cependant, il rappelle aussi que rien n’atteste que la signature appartienne à son propriétaire. Je vous renvoie à mon précédent billet sur PGP où j’expliquais rapidement comment les signatures de clés permettent d’apporter une preuve sociale de l’authenticité de celle-ci.

En signant avec ma propre clé celle de Fedora, je considère que j’ai confiance en celle-ci et l’indique à gpg. Le résultat est ainsi différent.

$ gpg --sign-key fedora-33-primary@fedoraproject.org

(...)
Voulez-vous vraiment signer ? (o/N) o


$ gpg --verify-files *-CHECKSUM
gpg: Signature faite le ven. 23 oct. 2020 17:09:17 CEST
gpg:                avec la clef RSA 963A2BEB02009608FE67EA4249FD77499570FF31
gpg: vérification de la base de confiance
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: profondeur : 0  valables :   2  signées :   1
     confiance : 0 i., 0 n.d., 0 j., 0 m., 0 t., 2 u.
gpg: profondeur : 1  valables :   1  signées :   0
     confiance : 1 i., 0 n.d., 0 j., 0 m., 0 t., 0 u.
gpg: la prochaine vérification de la base de confiance aura lieu le 2037-01-08
gpg: Bonne signature de « Fedora (33) <fedora-33-primary@fedoraproject.org> » [totale]

Git propose la même chose avec la possibilité de signer son travail, ce qui permet de créer une source de confiance pour l’origine des commits obtenus. En effet, pour Git, l’auteur d’un commit est là pour savoir qui a travaillé sur quoi au sein des collaborateurs du repository. A aucun moment il ne va chercher à authentifier une personne, ce n’est pas son objectif premier.

De ce fait, en renseignant dans son git config user.name et user.email le nom et l’email de quelqu’un d’autre, on peut potentiellement se faire passer pour cette personne en apparence… Evidemment Git ne permettra pas de pousser sur les repositories appartenant à quelqu’un d’autre car l’authentification gérée par l’hébergeur le bloquera. Néanmoins, cela suscite deux questions :

  • L’auteur du commit est-il vraiment la personne derrière le commit ?
  • Les changements apportés par ce commit sont-ils ceux que l’auteur a écrit ?

Un des scénarios peut être une personne malintentionnée qui introduirait du code malicieux dans un programme en le poussant sous le couvert d’une autre identité.

C’est là que le signature prend tout son sens.

Mais attention ! Si le véritable auteur signe ses commits, son nom peut toujours être usurpé. Le badge verified qui apparaît chez les différents hébergeurs ou dansgit log sont un contrôle supplémentaire à avoir.

Exemple de vérification avec Git dans le repo qui contient mon blog :

$ git log --show-signature 

commit 279ebef625982a51461a3ccc584dedf96e4dc835
gpg: Signature faite le mer. 13 janv. 2021 10:54:38 CET
gpg:                avec la clef RSA BCE31FF866963F1B141C90A04C47CF1D8592D50F
gpg:                issuer "seb@zedas.fr"
gpg: Bonne signature de « Seb <seb@zedas.fr> » [ultime]
gpg:                 alias « Seb <seb+blog@zedas.fr> » [ultime]
Author: Seb <seb@zedas.fr>
Date:   Wed Jan 13 10:54:38 2021 +0100

    test signe

commit 8519133ce6f48b029826a57ab1dc6b6b9de19167
Author: Seb <seb@zedas.fr>
Date:   Tue Jan 12 16:08:36 2021 +0100

    about

Le deuxième commit n’est pas signé, cela date d’avant que je me mette à le faire.

En graphique :

verified

Pour ajouter une couche de sécurité, il est possible d’adopter une politique indiquant que seuls les commits signés peuvent être fusionnés dans la branche principale. La plupart des hébergeurs le proposent dans les options de sécurité des branches. Attention, cela implique que tous les collaborateurs doivent avoir leur clé PGP et savoir signer leurs commits !

Exemple avec Gitea :

gitea

Activer la signature des commits et tags dans Git

Je partirais du principe que vous avez déjà votre clé privée et publique et en connaissez l’identifiant.

Tout d’abord, nous devons dire à Git quelle clé utiliser dans le cas où vous en auriez plusieurs.

$ git config --global user.signinkey <key ID>

A partir de là, vous pouvez signer vos commits avec Git ou vos tags en ajoutant simplement l’argument -S à la commande.

$ git commit -S
$ git tag -S

La passphrase de la clé privée sera demandée pour la débloquer.

Ensuite, vous pouvez demander à Git de systématiquement signer.

$ git config --global commit.gpgsign true
$ git config --global tag.gpgsign true

Maintenant, pour que vous apparaissez comme “verified” chez votre hébergeur, il faut deux éléments :

  1. S’assurer que l’adresse email que vous utilisez dans user.email est celle rattachée au compte de l’hébergeur
  2. Fournir à votre hébergeur votre clé publique

Sur Gitea, vous pouvez publiquer votre clé publique en allant dans votre profile => Settings => SSH / GPG Keys. Cliquez sur “add key” et collez dans la zone de texte le contenu de votre clé publique.

Sur GitHub, c’est un peu la même chose en allant dans les Settings de son compte => SSH / GPG Keys. Cliquez sur “New Key” et collez dedans votre clé publique.

Et voilà !