Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 622
    Points : 21 404
    Points
    21 404

    Par défaut 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.

    Nom : git-logo_bv0ydu.jpg
Affichages : 5620
Taille : 27,8 Ko

    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.

    Nom : find object.png
Affichages : 5025
Taille : 30,3 Ko

    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.

    Nom : color-moved.png
Affichages : 5175
Taille : 71,7 Ko

    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 ?

    Que pensez-vous de ces nouvelles fonctionnalités ?

    Laquelle vous paraît la plus utile ?

    Voir aussi

    GitHub veut développer un nouvel éditeur de texte multiplateforme et ultraperformant basé sur Electron, Xray est encore un projet expérimental
    GitHub : des chercheurs estiment que plus de la moitié des codes écrits en Java, Python, C/C++ et JavaScript sont dupliqués
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    208
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 208
    Points : 627
    Points
    627

    Par défaut

    Citation Envoyé par Patrick Ruiz Voir le message

    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...

  3. #3
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    septembre 2007
    Messages
    7 139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 139
    Points : 22 615
    Points
    22 615

    Par défaut

    Citation Envoyé par captaindidou Voir le message
    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.

  4. #4
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 783
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 783
    Points : 2 951
    Points
    2 951

    Par défaut

    Très très bon outil Git
    Rem: il n'y a pas que Github comme répo, il y a aussi Gitlab, Bitbucket.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  5. #5
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 511
    Points : 13 807
    Points
    13 807

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

    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.

    Nom : git-logo_bv0ydu.jpg
Affichages : 3558
Taille : 27,8 Ko

    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 ?

    Mettez-vous régulièrement à jour votre version de Git ?
    Faites-vous attention à ce que votre infrastructure utilise également des logiciels à jour ?
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

Discussions similaires

  1. Réponses: 0
    Dernier message: 15/03/2018, 09h24
  2. Réponses: 0
    Dernier message: 25/02/2015, 13h47
  3. Le framework open source Django sort en version 1.7
    Par Hinault Romaric dans le forum Django
    Réponses: 9
    Dernier message: 13/09/2014, 11h31
  4. Réponses: 2
    Dernier message: 21/06/2012, 23h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo