pylapp

Git

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.

Affichage d'un commit Git. On distingue notamment une section \

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.

Extrait de l'interface web de GitHub indiquant que le commit concerné est bien cryptographiquement vérifié

Affichage d'un commit Git. On distingue entre autres une rubrique concernant la clé GPG utilisée avec la cryptographie utilisée et l'empreinte de la clé ainsi que l'adresse email utilisée

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.

Message indiquant que le commit concerné est bien cryptographiquement vérifié

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 —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0 Opinions are my own, even if I have some interests. For any comment or to contact me, feel free to choose the most suitable medium for you.

Some words about secrets leaks in Git repositories

🇺🇸 – Sunday, March 6th 2022

Keywords: #Git, #GitLeaks, #leaks, #secrets, #repository

We all know it could be quite easy to leak secrets or sensitive data in our Git repositories.

In most of cases we just acted too fast, or were not aware we added in the version control systems (VCS) such sensitive files or objects. Bad SSH configuration with private or public keys in the VCS tree, API keys defined in hard-coded variables in the source code, keystore files with credentials in the Gradle files (including alias, key and password of course), IP addresses, sensitive URL, and so on.

And when we work on public or shared repositories, we have all those sensitive data spread outside!

When people get noticed of these leaks, they may apply bad patterns to fix these issues, for example :

  • Make a commit “just to remove the change”, (useless because the Git history still contains the data)
  • Make the project private (bad, because users won't be able to get it)
  • Delete the repository (useless if there are forks of it)

One tool can be useful, Gitleaks.

Note that Gitleaks looks both in the files tree of the project and the Git history. That's a reason why we must not make such “fix commit” because the history keeps traces of what we do and tried to hide.

So, I would like to share three useful and cool things:

The command to run Gitleaks is very simple:

Shell command to run gitleakswhere. json is the type ouf output for the report called report.json created after the scan of your git repository named folder.

Beware if you scan big repositories (like a fork or a project with an old history), Gitleaks will take long time to run.

In addition, the Git configuration value diff.renameLimit should be updated to allow Gitleaks to work.

Note that the Orange group provides a GitLab CI template dedicated to GitLeaks with the To Be Continous project! Get it here.

Have fun by scanning your projects! — Last update: Wednesday, August, 10th 2022 Previously on Medium and paper.wf —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 4.0 Opinions are my own, even if I have some interests. For any comment or to contact me, feel free to choose the most suitable medium for you.