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