Au fait, pensez-vous à signer vos commits ?

🇫🇷 – mercredi 8 juin 2022

Mots clés : #Git, #commits, #GPG, #signature, #cryptographie

Au jour d'aujourd'hui il est indéniable que le code source a une valeur concrète, tant pour ce qui est de la propriété intellectuelle et du patrimoine logiciel qui en découle que pour les sommes investies pour son écriture. En 2009, un article de silicon.fr est paru et évoquait le fait que la valeur des logiciels open source est estimée à 400 milliards de dollars américains, explosant les quelques 25 milliards de dollars américains pour l'écosystème Linux !

Le fait est qu'il faut être capable de définir, et surtout certifier, qui est l'auteur des commits pour savoir à qui appartient la contribution induite. Lorsque des entreprises travaillent avec des filiales ou des prestataires, ou quand du code source est cédé à une fondation ou un organisme tiers, voire même si les projets open source sont critiques, certifier l'origine du commit est rassurant.

Certes, on pourrait se contenter de regarder l'identité de l'auteur, avec par exemple la bonne vieille commande git log, permettant de ressortir l'historique Git et d'obtenir des détails sur les derniers commits.

Sauf que le champ Author d'un commit est définit par deux éléments : les champs user.name et user.email de la configuration Git (locale ou globale). Or, ces champs peuvent être définis par n'importe qui, avec n'importe quelle valeur, sans vraiment de contrôle naïf et natif sur ça. Ils ne sont donc pas à considérer comme fiables.

On pourrait aussi regarder du côté du Developer Certificate of Origin (DCO), avec notamment l'option -s dans la commande Git de commit. Or le DCO n'est pas dédié à cette question, mais plutôt au fait que l'on confirme avoir les autorisations qui vont bien pour faire ce commit, apporter cette contribution, dans le respect des licences par exemple. C'est intéressant, mais pas adapté.

On peut par contre considérer la signature des commits via... une clé GPG (option -S).

L'idée est simple finalement : on créé une clé GPG, on la dépose dans son compte sur sa forge logicielle (GitHub ou GitLab par exemple), et on définit dans le dépôt en local la clé à utiliser (user.signingkey). Ainsi, on peut plus fortement confirmer que le commit est bien signé par une personne via sa clé GPG avec la même adresse e-mail entre celle du commit et celle de la clé. C'est d'ailleurs très pratique car via sa forge on peut facilement voir que le commit est vérifié (ellipse bleue), avec une clé GPG d'identifiant donné (rectangle vert), et d'ailleurs signé avec le DCO (rectangle rouge). Bon le hic c'est qu'il faut être capable d'avoir une autorité permettant de vérifier les clés, ou alors de placer une confiance aveugle envers la forge logicielle concernée dont peut-être les administrateurs seraient peu scrupuleux et capables d'altérer les clés publiques enregistrées. À creuser en tout cas.

Ce faisant, il est même possible de vérifier a posteriori la signature d'un commit via la commande git show [commit] —show-signature, ou plus appropriée la commande git verify-commit [commit] qui renvoie le strict nécessaire en terme d'informations.

Remarque, ce serait intéressant d'avoir des hooks vérifiant au moment du commit s'il est bien signé. Dans des projets critiques ou sensibles, on saura ainsi s'il n'y a pas un contributeur tiers qui aurait commis des commits sans autorisation. Ce n'est pas suffisant, mais ça aide.

On peut ainsi voir que pour le commit donné, il y a bien eu une signature avec une clé GPG de type EDDSA avec l'identifiant indiqué (dont on retrouve une partie à la fin), et une note indiquant que c'est bien la bonne adresse email qui est utilisée.

Bref, pensez à signer vos commits. C'est rigolo et ça fait classe.

Pour en savoir davantage, je vous conseille cet article assez simple et aussi cette page de la documentation GitHub à propos d'une nouvelle fonctionnalité chez eux : “le mode vigilant”.

— Dernière mise à jour : lundi 3 octobre 2022 Précédemment sur paper.wf —