Signer nos commits

Article écrit par Jonathan Francois

Contexte

Aujourd’hui nous essayons au maximum de sécuriser nos différentes communications. Que ce soit par l’utilisation de messagerie sécurisée ou par l’utilisation de clé GPG pour nos mails par exemple. D’une part cela permet une certaine confidentialité de nos données mais également d’éviter les usurpations d’identités.

Il y a moins d’un mois (fin mars 2021), cela a failli avoir de gros impacts pour la communauté PHP. Deux « hackers » ont tenté d’injecter une backdoor dans le code source du langage (git.php.net) en utilisant le nom des deux principaux développeurs du langage de programmation, Rasmus Lerdorf et Nikita Popov. Ces commits étaient présentés comme de simples résolutions d’erreurs de typographie, avec pour objectif caché la création d’une porte dérobée et donc la possibilité d’exécuter du code à distance.

Heureusement, les failles ont été corrigées avant qu’elles n’aient pu affecter la communauté et les utilisateurs des applications en PHP.

Pour réaliser cette action, les hackers ont dû avoir un accès au gestionnaire de code git.php.net et utiliser l’identité de vrais développeurs pour passer leur code.

Concernant le premier point, nous n’en savons pas plus à l’heure actuelle (pas réalisé de grosses recherches non plus) mais concernant le second il est sûr que les développeurs n’utilisaient pas de clé GPG permettant de vérifier l’identité de leur commit. C’est tout l’objet de cette note rapide.

Configurer et sécuriser l’identité de nos commits

Que ce soit dans des projets OSS ou au sein de votre société, vous avez certainement déjà vu dans l’historique des badges de signature de commit et/ou de commit signé/vérifié.

Cela permet au-delà de l’authentification de votre gestion de code, de vérifier l’identité de la personne responsable de celui-ci.

Mais comment mettre cela en place dans votre équipe pour éviter les surprises ?

Tout d’abord il faut avoir une clé GPG, pour ceux qui n’en ont pas encore pour les mails ou autres je vous conseille de le faire rapidement (pour l’installation https://gpgtools.org/ pour osx et https://gnupg.org/ pour linux) :

gpg --list-keys  # Verifier les clés existantes gpg --gen-key    # Générer une nouvelle clé 

Une fois votre clé générée, identifions votre identifiant de clé :

gpg --list-secret-keys --keyid-format LONG <VOTRE_EMAIL> 

Ensuite configurons notre client git :

git config --global user.signingkey <ID_GPG> git config --global commit.gpgsign true # Pour éviter de passer l'argument `-S` à chaque commit sinon `git commit -S -m "First commit"` 

Maintenant il faut ajouter votre clé publique dans votre gestionnaire de code. Cela se passe généralement dans votre profil (c’est le cas pour GitLab et GitHub).

Pour connaitre votre clé publique GPG, vous pouvez utiliser la commande suivante :

gpg --armor --export <ID_GPG> 

Pour que cela soit fonctionnel il faut que votre clé GPG comporte l’email que vous utilisez dans votre configuration du client Git.

$ cat ~/.gitconfig [user] 	name = Jon 	email = <VOTRE_EMAIL> 	signingkey = <ID_GPG> 

Besoin de plusieurs identités ?

Il est possible que vous ayez besoin d’avoir des identités différentes en fonction de vos projets. Dans ce cas, il est possible de le spécifier via des fichiers de configuration git spécifiques par dossier.

# ~/.gitconfig [includeIf "gitdir:~/sources/synbioz/"] path = .gitconfig-synbioz 

# ~/.gitconfig-synbioz [user] name = Jonathan Francois email = jfrancois@synbioz.com 

Dans ce cas, nous aurons une identité différente dans tous les projets git se trouvant dans le dossier ~/sources/synbioz/. La configuration est fusionnée, le fichier spécifique surcharge les clés du ~/.gitconfig.

Conclusion

Une fois cette configuration faite pour l’ensemble des équipes, vous pouvez bloquer les commits non signés sur GitLab ou GitHub.