Publication de la v2.17.1 de Git qui corrige une vulnérabilité sévère

La version 2.17 de Git, l’outil open source de gestion de versions, est disponible
Et intègre de nouvelles fonctionnalités dont une d’accélération

L’équipe du projet Git annonce la disponibilité de la version 2.17 de Git, l’outil open source de gestion de versions des logiciels. GitHub, la plateforme d’hébergement et de gestion de développement de logiciel, s’est fait le relais de l’information.

Cette version intègre des correctifs relatifs à des comportements erratiques de certaines commandes disponibles. La liste est assez longue et comprend git status, git commit, git add – des commandes de base de l’outil – qui causaient des soucis dans la version 2.16 de l’outil de gestion de versions. Le détail à ce propos dans la note de version détaillée. Avec Git 2.17, il faut également s’attendre à un minimum de trois nouvelles fonctionnalités qui sautent à l’œil : coloration de code déplacé, accélération et recherche d’objets.

Pièce jointe 368185

Git 2.17 est synonyme d’accès rapide à l’information. Cette version est en effet dotée d’une fonctionnalité de recherches d’objets au sein de l’historique intégré au logiciel. Les utilisateurs de l’outil de gestion de versions disposent désormais de la commande --find-object à utiliser en tandem avec un hash d’objet pour faire apparaitre tous les nœuds de l’arborescence contenant ce dernier – ou une modification – au sein de l’arborescence. Plutôt intéressant puisque la fonctionnalité retourne les chemins d’accès.

Pièce jointe 368189

L’un des problèmes auquel les développeurs qui travaillent sur des projets avec un nombre de fichiers très important est que le temps de réponse de la commande git status augmente considérablement. Git 2.17 vient avec watchman pour apporter réponse à cet état de choses en court-circuitant l’appel système status() et ses accès en lecture répétés sur le disque dur.

L’outil permet de rendre la charge de travail liée au suivi des modifications proportionnelle au nombre de fichiers modifiés en s’appuyant sur le système d’exploitation lui-même, ce qui raccourcit les temps d’attente. Watchman – proposé par Facebook sous licence Apache 2.0 – est disponible sur Windows (7 et versions ultérieures), Linux et macOS (10.X). Enfin, rien de tel qu’un bon visuel pour introduire à la dernière fonctionnalité phare de cette version.

Pièce jointe 368193

Avec Git 2.17, les développeurs disposent de la commande --color-moved. À utiliser dans les cas de passage en revue de commits pour savoir quelles sections de codes ont fait l’objet de déplacements. En guise de résultat, la commande renvoie une version du commit colorée en conséquence. L’équipe du projet précise que les couleurs sont configurables. Dans cet exemple, le bleu représente les portions de code déplacées d’une zone à l’autre du texte tandis que le vert et le rouge mettent les modifications au sein de ces blocs en lumière.

Grosso modo, c’est GitHub qui, en plus de l’outil git-sizer annoncé le mois passé, s’enrichit de fonctionnalités qui étendent encore plus l’arsenal du développeur. Toutefois, attention, car ceux qui ont fait le choix de plateformes alternatives comme gitweb, Gitstack, Gitlab, etc. peuvent également profiter de ces nouveautés. À chacun ses préférences.

Source

Blog GitHub

Et vous ?

:fleche: Que pensez-vous de ces nouvelles fonctionnalités ?

:fleche: Laquelle vous paraît la plus utile ?

Voir aussi

:fleche: GitHub veut développer un nouvel éditeur de texte multiplateforme et ultraperformant basé sur Electron, Xray est encore un projet expérimental
:fleche: GitHub : des chercheurs estiment que plus de la moitié des codes écrits en Java, Python, C/C++ et JavaScript sont dupliqués

Citation:

---

Envoyé par Patrick Ruiz

Cette version intègre des correctifs relatifs à des comportements erratiques de certaines commandes disponibles. La liste est assez longue et comprend git status, git commit, git add – des commandes de base de l’outil – qui causaient des soucis dans la version 2.16 de l’outil de gestion de versions. Le détail à ce propos dans la note de version détaillée.

---

Comment des commandes de base peuvent-elles être encore erratiques à ce stade du cycle de vie ? C'est impensable...

Citation:

---

Envoyé par captaindidou

Comment des commandes de base peuvent-elles être encore erratiques à ce stade du cycle de vie ? C'est impensable...

---

Je pense qu'il s'agit d'un raccourci un peu rapide. Je n'ai rien vu « d'erratique » à proprement parler dans le blog et de toutes façons, il s'agit de correctifs depuis la version 2.16 (soit la précédente), et pas de quelque chose qui serait resté en suspens depuis la sortie de Git en 2005 (13 ans ce mois-ci tout de même). En ce qui concerne les notes de versions fournies dans le dépôt lui-même, on voit toutes sortes de choses, dont pas moins de 46 entrées dans la section bugfixes en particulier. Celles qui évoquent les commandes en question sont celles-ci :

Citation:

---

Envoyé par Relnotes 2.17

* "git status" after moving a path in the working tree (hence making
it appear "removed") and then adding with the -N option (hence
making that appear "added") detected it as a rename, but did not
report the old and new pathnames correctly.

[…]

* "git commit --fixup" did not allow "-m<message>" option to be used
at the same time; allow it to annotate resulting commit with more
text.

[…]

* "git add -p" was taught to ignore local changes to submodules as
they do not interfere with the partial addition of regular changes
anyway.

[…]

* "git add" files in the same directory, but spelling the directory
path in different cases on case insensitive filesystem, corrupted
the name hash data structure and led to unexpected results. This
has been corrected.
(merge c95525e90d bp/name-hash-dirname-fix later to maint).

[…]

* "git commit" used to run "gc --auto" near the end, which was lost
when the command was reimplemented in C by mistake.
(merge 095c741edd ab/gc-auto-in-commit later to maint).

---

… et en fait, on s'aperçoit que toutes les commandes ou presque sont concernées dans le reste de la liste. Donc il s'agit de correctifs ordinaires même à ce stade du développement, voire même de comportements indésirables dans certains cas, plus que de réels bugs.

Par ailleurs, en lisant en diagonale le blog en question, on trouve d'autres infos intéressantes sur lesdites commandes. On peut d'abord y lire que cette version bénéficie de « features and bugfixes » (donc correctifs ET fonctionnalités) de la part d'une soixantaine de collaborateurs.

Ensuite, en faisant une petite recherche avec le mot « status », on arrive tout de suite au paragraphe qui traite de cette commande en particulier, où il est en fait question de l'accélérer (plus encore qu'elle l'est déjà). Il y est expliqué en substance que pour vérifier si un fichier suivi a besoin d'être contrôlé ou non, Git commence par appeler stat() (qui est l'appel système qui sert à obtenir les méta-informations d'un fichier, notamment sa taille et sa date de dernière modification) et que s'il est avéré que le fichier n'a pas bougé depuis la dernière fois (car cette information peut aussi être indisponible, auquel cas il faut faire le contrôle), eh bien il s'épargne tout simplement cette peine, avec raison.

Ça permet de ré-insister sur un point assez notable, par rapport à un DVCS incrémental qui stocke ses diffs consécutivement dans un fichier : le système d'objets permet à Git de re-déléguer au système de fichiers tout ce qui aurait dû le rester depuis toujours : disponibilité, intégrité du contenu, sauvegarde, mise en cache et indexation pour une récupération rapide (par rapport à un parcours séquentiel de l'historique des modifs dans le cas d'un fichier unique, par exemple). Et en ce sens, le choix du système de fichiers sur lequel on va ouvrir tous les dépôts va avoir un impact non-négligeable sur les performances d'un service Git déployé à grande échelle. D'ailleurs, en 2005, dans une de ses présentations en public, Linus se plaignait ouvertement des performances de celui de Windows à ce sujet. Ça a dû changer depuis… Ça va aussi être particulièrement vrai si l'on utilise un système de fichiers en réseau ou un lecteur partagé. Même si, là encore, l'architecture distribuée de Git est justement conçue pour éviter d'avoir à le faire.

Ce qui est expliqué dans le blog à ce sujet, donc, c'est qu'il est maintenant possible depuis 2.16 (la précédente version) de mettre en place un hook pour déléguer cette tache à un programme qui en aura la charge et auquel Git se fiera, plutôt qu'appeler lui-même stat() à tout bout de champ, ce qui permet de faire de substantielles optimisations dans un environnement industriel. Et à dire vrai, il est dit que l'interface est universelle et peut être utilisée avec n'importe quoi mais qu'elle a surtout été mise en place pour permettre l'utilisation de watchman.



Autre chose intéressante : on y apprend qu'il y a bien un plan de migration en train d'être mis en place pour quitter SHA1 au besoin, suite à la récente découverte d'une méthode de collision artificielle. Si cela ne remet en aucune façon en cause l'architecture de Git elle-même et que le logiciel pourrait s'appuyer a priori sur n'importe quelle fonction de hachage rendant les mêmes services, migrer un dépôt de l'une vers l'autre, faire un plan de transition et coordonner tous les dépôts décentralisés qui, par nature, sont indépendants les uns des autres est une vraie gageure (et un authentique projet d'ingénierie, à mon avis). C'est une bonne chose de savoir qu'un groupe de travail est d'ores et déjà en place pour plancher sur cette question.

Très très bon outil Git :)
Rem: il n'y a pas que Github comme répo, il y a aussi Gitlab, Bitbucket.

Publication de la v2.17.1 de Git qui corrige une vulnérabilité sévère,
permettant l'exécution d'un code arbitraire lors du clone d'un dépôt malicieux.

Le 29 mai dernier, gitster le mainteneur du projet Git a annoncé sur la liste de diffusion du projet la publication de la version v2.17.1 de Git afin de corriger une faille de sécurité sévère nommée CVE-2018-11235.

Des patchs correctifs ont également été publiés via les tags v2.13.7, v2.14.4, v2.15.2 et v2.16.4 sur les branches en maintenance.

Pièce jointe 384873

Que fait cette vulnérabilité ?

Cette vulnérabilité n'affecte que les dépôts contenant des sous-modules et exécutant un clone récursif des sous-modules (git clone --recurse-submodules). Elle consiste en l'exécution du hook post-checkout d'un sous module malicieux.

Normalement les scripts de hooks ne font pas partie des dépôts Git. Ils sont générés par Git lors du clone et non lus depuis le serveur. Dans ce cas de figure, des hooks définis dans un sous-module construit avec des chemins d'accès appropriés (via ../ par exemple ou un lien symbolique) peuvent être lus et exécutés dès la fin du clone récursif via le hook post-checkout (lequel s'exécute dès qu'un fichier versionné est placé dans l'espace de travail, donc dans ce cas de figure lors du checkout du sous module vérolé par le dépôt parent).

Que fait le patch ?

Il interdit tout simplement la configuration d'un sous module (fichier .gitmodules) avec un chemin d'accès contenant un segment ../.

Impact sur l'écosystème ?

Git n'est pas utilisé seulement par les développeurs comme SCM, il est également utilisé comme vecteur de déploiement dans pas mal de cas ce qui augmente considérablement l'impact de cette faille.

Le gestionnaire de paquets JavaScript npm ne limite pas les dépendances à des paquets construits via npm et hébergés sur le registre. On peut tout à fait définir une dépendance comme étant un dépôt Git quelconque. Dans ce cas de figure le client npm délègue au Git installé localement l'installation (le clone donc) du dépôt. L'équipe npm a donc publié sur son blog une recommandation visant à contrôler sa version locale de Git et à la mettre à jour si besoin.

De même l'équipe Microsoft gérant le Visual Studio Team Services (VSTS) bloque désormais tous les dépôts contenant une telle configuration afin de ne pas servir de vecteur d'attaque. Edward Thomson a publié un billet sur le blog DevOps de Microsoft à ce sujet.

Les autres hébergeurs classiques de dépôts comme GitHub et GitLab ont également pris des mesures en ce sens, ainsi un développeur souhaitant pousser un dépôt démontrant la vulnérabilité n'a pas pu et indique seulement comment générer un tel dépôt.

Sources 
- Liste de diffusion du projet Git.
- Le blog DevOps de Microsoft.
- Le blog officiel de npm, Inc.
- Ticket de la vulnérabilité CVE-2018-11235 sur mitre.org.

Et vous ?

:fleche: Mettez-vous régulièrement à jour votre version de Git ?
:fleche: Faites-vous attention à ce que votre infrastructure utilise également des logiciels à jour ?