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Ă  !