Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.)

Posté par (page perso) . Édité par Benoît Sibaud et Bruno Michel. Modéré par Christophe Guilloux. Licence CC by-sa
42
19
déc.
2014
Sécurité

Une vulnérabilité (CVE-2014-9390) a été annoncée hier soir concernant le logiciel de gestion de versions le plus en vogue en ce moment, j'ai nommé Git, ainsi que sur Mercurial, autre logiciel de la même catégorie. Elle a déjà été corrigée, je vous invite donc à mettre à jour vos installations.

Github, le service d'hébergement de dépôt Git lui aussi très en vogue, a de son côté annoncé avoir vérifié tous les dépôts présents sur ses serveurs à la recherche d'exploitations de cette vulnérabilité. Mesure de sécurité supplémentaire, il refuse désormais les push exploitant cette faille.

NdM : Merci à RoM1 et Sébastien Douche pour les précisions apportées dans la dépêche. La faille a été trouvée par le créateur de Mercurial, Matt Mackall, et Augie Fackler. La vulnérabilité se décline en trois parties :

  • la sensibilité à la casse dans Git, déjà corrigé dans Mercurial en 2008 ;
  • l’expansion des noms courts sous Windows (PROGRA~1 → Program Files), déjà corrigé dans Mercurial ;
  • la découverte récente de la façon non documentée dont Darwin (Apple) s’amuse avec HFS+ à ignorer certains caractères spéciaux et qui peut créer de nouvelles collisions de nom (cf la correction chez Mercurial, qui a permis la correction côté Git).

Cette vulnérabilité concerne le fichier .git/config qui définit les paramètres du dépôt de travail[1]. Elle fonctionne sur les systèmes de fichiers non sensibles à la casse, comme les systèmes de fichiers de Microsoft (FAT ou NTFS) ou celui d'Apple (HFS+).

Son fonctionnement est très simple. Sur ces systèmes de fichiers, si on clone un dépôt Git contenant un fichier .Git/config, ce fichier viendra alors écraser le fichier .git/config. À partir de là, on peut imaginer une pléthore d'exploitation (ce travail est laissé au lecteur).

Cette faille soulève la question de la gestion des divers systèmes de fichiers qui gèrent chacun différemment les noms de fichiers. L'annonce du correctif indique qu'en plus du simple cas de la casse, certains systèmes de fichiers peuvent avoir d'autres cas de collision, comme par exemple git~1/config qui sous Windows se verra traité comme .git/config.

La solution pour une interopérabilité maximale est de se réduire au plus grand sous-ensemble commun, et c'est désormais ce que fait Git par défaut (comportement paramétrable cependant).

[1] Par « dépôt de travail » on entend un dépôt qui n'est pas bare (non créé avec git init --bare), et donc dans lequel on peut effectivement travailler.

  • # Linux power!

    Posté par (page perso) . Évalué à 6.

    Linux power! C'est tout!

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Linux power!

      Posté par (page perso) . Évalué à 5.

      Je pense que si tu utilises un système de fichier insensible à la casse sous linux, tu vas souffrir aussi :-)

      • [^] # Re: Linux power!

        Posté par . Évalué à -6.

        ah oui ? lequel ? c'est une question ;-)

        • [^] # Re: Linux power!

          Posté par . Évalué à 5.

          Ils sont cités dans la dépêche.

          • [^] # Re: Linux power!

            Posté par . Évalué à 2.

            je doute que beaucoup de monde utilise du fat32 ou du NTFS pour son /home et a fortiori gérer ses dépôts sur de tels FS, mais bon, tout est possible c'est vrai.
            De façon générale, les FS sans gestion de la casse, c'est la galère…

            • [^] # Re: Linux power!

              Posté par (page perso) . Évalué à 6.

              Un jour, un FAT32 sur clé USB te surprendra car personne ne s'attend à travailler sur du FAT32.

              • [^] # Re: Linux power!

                Posté par . Évalué à 0.

                oui ça peut arriver. De toute façon on peut s'attendre à tout en utilisant fat32 / ntfs

            • [^] # Re: Linux power!

              Posté par . Évalué à -7.

              C'est galère sur un OS pas conçu pour, pour les autres c'est tout à fait transparent.

              • [^] # Re: Linux power!

                Posté par . Évalué à 1.

                oui, genre tu dois récupèrer des fichiers avec le même nom et des casses différentes depuis un ftp ou une archive zip, ton super OS « conçu pour » il fait comment ? C'est toujours aussi transparent ?

                • [^] # Re: Linux power!

                  Posté par . Évalué à 0.

                  Avec un soft concu proprement oui, quand il se rend compte qu'un fichier avec le meme nom existe deja, il devrait ouvrir un prompt avec un avertissment si il est ecrit proprement.

                • [^] # Re: Linux power!

                  Posté par (page perso) . Évalué à -4.

                  genre tu dois récupèrer des fichiers avec le même nom et des casses différentes

                  Après, on peut se demander le niveau d'une personne qui écrit un nom de fichier dont la différence avec le voisin et la casse.
                  Je serai tenté de dire que le problème est plutôt l'OS qui laisse passer ce genre de chose parce qu'il a eu la flemme d'implémenter une comparaison de casse bref qui veut faire croire qu'un manque de fonctionnalité est une fonctionnalité, mais tu ne va pas vouloir imaginer une critique sur ton OS préféré.

                  Pour ton OS, zUrvan est différent de zurvan, mais j'avoue que je ne fais personnelement pas la différence, je penserai que c'est le même pseudo.

                  PS : je m'étonne de ne jamais avoir vu des critique sur le manque de casse des noms de domaine.

                  • [^] # Re: Linux power!

                    Posté par . Évalué à 9.

                    Pour ton OS, zUrvan est différent de zurvan, mais j'avoue que je ne fais personnelement pas la différence, je penserai que c'est le même pseudo.

                    tU pEnSeS vRaImEnT qUe Ça Ne FaIs AuCuNe DiFféReNcE, zEnItRaM ?

                  • [^] # Re: Linux power!

                    Posté par . Évalué à 1.

                    PS : je m'étonne de ne jamais avoir vu des critique sur le manque de casse des noms de domaine.

                    Mauvaise analogie. Les paths d'url sont sensible a la casse, ou pas, comme les systemes de fichiers, en fait, c'est a l'implementation de choisir.

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: Linux power!

                      Posté par (page perso) . Évalué à 7.

                      Qu'est-ce que tu n'as pas compris dans « nom de domaine » ?

                      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                      • [^] # Re: Linux power!

                        Posté par . Évalué à -1.

                        Qu'est ce que tu n'as pas compris dans "mauvaise analogie"?

                        Que les noms de domaines soient case insensitive n'est tres pertinent, ce qui se compare le mieux a un chemin de fichier, c'est un chemin d'url, vu que c'est un peu la meme chose au final.

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                        • [^] # Re: Linux power!

                          Posté par (page perso) . Évalué à 2.

                          Oui, et dans une URL, une partie est case sensitive, et une autre est case insensitive, le bonheur pour les comparaisons
                          Le nom de domaine est justement le sujet.
                          L'exemple de l'URL est juste un bonus avec un mix (l'enfer pour un développeur qui doit comparer).

                  • [^] # Re: Linux power!

                    Posté par . Évalué à 9.

                    Après, on peut se demander le niveau d'une personne qui écrit un nom de fichier dont la différence avec le voisin et la casse.

                    Après on peut se demander le niveau d'une personne qui ne comprends pas vraiment les problèmes que ça pose.

                    Le case insensitives ne devrait pas être géré au niveau du système de fichier, comme la traduction des dossiers ou les fichiers cachés. Le faire au niveau du système de fichier ça pose des problèmes complexes à résoudre dans un tas de logiciel notamment pour les gestionnaires de versions (il faut vraiment faire gaffe avec svn pour renommer un fichier en changeant uniquement la casse de sont nom).

                    Mais ta vision est très limité, tu peut très bien avoir une application qui se sert du système de fichier comme moteur de persistance, tu peut très bien avoir des utilisateurs (dont tu peut te questionner de leur niveau) pour qui menton.jpg et Menton.jpg ont 2 significations très différentes,.. bref tu peut avoir pleins de choses et le fait de mettre cette limitation dans le système de fichier est très bloquant alors qu'il pourrait très bien être géré à plus haut niveau.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Linux power!

                      Posté par . Évalué à 9.

                      menton.jpg et Menton.jpg ont 2 significations très différentes

                      Ou plutôt: marguerite.jpg et Marguerite.jpg; le premier est une photo de la fleur, le second de ma grand-mère.

                      Hop,
                      Moi.

                      • [^] # Re: Linux power!

                        Posté par (page perso) . Évalué à 8.

                        Je pense que Menton faisait référence à la ville, donc son exemple est pertinent.

                        • [^] # Re: Linux power!

                          Posté par . Évalué à 3.

                          En effet j'aurais pu parler d'Orange ou de Monaco aussi.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Linux power!

                            Posté par (page perso) . Évalué à 2.

                            Ou d'ExpertsExchange.

                            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                    • [^] # Re: Linux power!

                      Posté par . Évalué à 6.

                      Le case insensitives ne devrait pas être géré au niveau du système de fichier, comme la traduction des dossiers ou les fichiers cachés. Le faire au niveau du système de fichier ça pose des problèmes complexes à résoudre dans un tas de logiciel notamment pour les gestionnaires de versions (il faut vraiment faire gaffe avec svn pour renommer un fichier en changeant uniquement la casse de sont nom).

                      Ça tombe bien, NTFS est case-sensitive. C’est l’api windows qui s’occupe de faire la traduction (de même pour les noms de fichier 8.3, etc). Et c’est très possible de passer outre, en utilisant les APIs adaptées.

                      Je crois que FAT32 sous linux peut l’être aussi (case-sensitive). D’ailleurs, fondamentalement, un chemin n’est pas vraiment une « chaîne de caractères », c’est plutôt une suite d’octets sans signification particulière, et surtout sans notion d’encodage (donc fatalement, ça ne peut pas être insensible à la casse, notion qui n’existe pas à son niveau). Ça pose notamment plein de problèmes amusants quand cette suite d’octet est invalide dans l’encodage par défaut du système (ceux qui ont migré une machine du latin1 vers l’utf-8 doivent savoir de quoi je parle).

                      Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                      • [^] # Re: Linux power!

                        Posté par (page perso) . Évalué à 2.

                        À ce propos : avec Linux, le chemin n'est qu'une suite d'octets. C'est à l'application de savoir quel est l'encodage utilisé, et tu peux tout à fait avoir dans le même dossier des fichiers avec différents encodages.
                        Avec OS X, le système de fichiers (ou le noyau ?) impose l'utilisation d'un encodage (et d'une normalisation Unicode) bien précis.
                        Je crois que Windows est comme Linux, mais s'attend à ce que ça soit de l'UTF-16 (sans normalisation précise).

                        • [^] # Re: Linux power!

                          Posté par . Évalué à 4.

                          Je crois que Windows est comme Linux, mais s'attend à ce que ça soit de l'UTF-16 (sans normalisation précise).

                          Il le stocke en UTF-16, surtout, il me semble. D'ailleurs pour accéder au système de fichiers sous Windows, il est conseillé d'utiliser les API unicode (celles terminant en W) plutôt que celles utilisant des chaînes 8 bit (celles terminant en A).

                          • [^] # Re: Linux power!

                            Posté par . Évalué à 2.

                            De manière générale, sous windows il vaut mieux utiliser les APIs W chaque fois qu’il y a le choix, et travailler en wchar_t (LPCWSTR si mes souvenirs sont bons). Attention toutefois à ne pas confondre deux choses dans le cas présent :
                            - les APIs unicodes (finissant en W)
                            - les « long path », commençant par \?.

                            Le deuxième n’est effectivement utilisable qu’avec les APIs unicode, mais utiliser les APIs unicode avec des chemins « standard » n’affranchit pas de la limite à MAX_PATH caractères.

                            Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                            • [^] # Re: Linux power!

                              Posté par . Évalué à 2.

                              Oui, et la syntaxe de chemins longs (commençant par \\?\) ne fonctionne qu'avec les chemins absolus. Encore une limitation chiante.

                              • [^] # Re: Linux power!

                                Posté par . Évalué à -1.

                                C'est pas une limitation, c'est un effet tout a fait normal. '\\?\' signifie au système: " n'essaye pas d'interpréter le chemin, envoie le directement au FS". Ca empêche évidemment toute résolution de chemins relatifs.

                                • [^] # Re: Linux power!

                                  Posté par . Évalué à 1.

                                  "it's not a bug, it's a feature!"

                                • [^] # Re: Linux power!

                                  Posté par . Évalué à 2.

                                  Oui… sauf qu'au point de vue de l'usage, cela veut dire qu'on ne peut faire sauter la limitation de la longueur des chemins que pour les chemins absolus.

                                  • [^] # Re: Linux power!

                                    Posté par . Évalué à 1.

                                    Tout a fait, il faut se mettre dans la tête que pour Win32, le chemin de path maximum est MAX_PATH (255) caractères. Le truc '\\?\' revient à faire un bypass de Win32, faut pas espérer que les softs Windows vont gérer cela vu que l'objectif de la chose est justement un bypass.

          • [^] # Re: Linux power!

            Posté par . Évalué à -3.

            Il voulait surement savoir lequels sous Linux!

  • # Pas que Git

    Posté par . Évalué à 10.

    Faille trouvée par le créateur de Mercurial, Matt Mackall. Cela touche aussi Hg puisque le principe est identique.

    • [^] # Re: Pas que Git

      Posté par . Évalué à 10. Dernière modification le 19/12/14 à 19:00.

      …et Augie Fackler.
      Et en fait c’est pas une vulnérabilité qui touche git, mais 3,
      - le problème de case-sensitivity, corrigé dans mercurial en 2008,
      - le problème d’expansion des noms courts sous windows (PROGRA~1 → Program Files), pareil, pas de souci pour hg,
      - et le réel nouveau problème, sous apple, lié à la découverte récente de la façon non docu dont Darwin s’amuse avec HFS+ à ignorer certains caractères spéciaux et qui peut créer de nouvelles collisions de nom ( http://selenic.com/hg/rev/885bd7c5c7e3 )
      C’est en voulant voir comment c’est géré chez leurs petits copains que les devs mercurial se sont rendus compte que git n’était pas du tout blindé à ce niveau.

      • [^] # Re: Pas que Git

        Posté par (page perso) . Évalué à 3.

        Merci pour les précisions, qui ont été ajoutées à la dépêche.

      • [^] # Re: Pas que Git

        Posté par (page perso) . Évalué à 9.

        Ça ne m'étonne pas que Mercurial ait vu le souci : ils ont l'air de se poser beaucoup de questions sur le sujet, tout comme les problèmes de collisions avec les fichiers qui ont des noms UTF-8 : il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être stocké comme un « è » ou comme un « e + ` »). Sur Linux, on aura donc plusieurs fichiers avec exactement le même nom (et de façon indiscernable pour l'application), alors que sur OS X le système de fichiers est normalisé (NFKD de mémoire) et il y aura un seul fichier (Windows est comme Linux, je crois).

        • [^] # Re: Pas que Git

          Posté par . Évalué à 1.

          il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être
          stocké comme un « è » ou comme un « e + ` »)

          Tu as de la doc là-dessus ? Je ne dis pas que c'est faux, mais c'est si contraire au fonctionnement d'UTF-8 et a priori d'un intérêt si marginal que ça me désarçonne un peu.

          En UTF-8, la séquence codant un caractère sur plusieurs octets indique via les bits à 1 (au minimum 2) démarrant le premier de ceux-ci combien d'octets elle occupe, chacun des autres octets commençant ensuite par un bit à 1 suivi d'un bit à 0. Ça permet de toujours pouvoir se situer dans une chaîne (si tu as un premier bit à 1, tu sais que tu es sur un caractère codé sur plusieurs octets, si le bit suivant est à 0, tu sais que c'est un octet intermédiaire et qu'il faut donc aller dans les octets précédents pour retrouver le premier et pouvoir reconstituer toute la séquence). Là, avec ce que tu décris, il faudrait avoir un octet spécial 111???? suivi par deux octets sur 7 bits 0???????, ça casse tout.

          • [^] # Re: Pas que Git

            Posté par (page perso) . Évalué à 9.

            Vous êtes complètement HS : UTF-8 est un format de codage d'Unicode (comme UCS4 par exemple). On s'en fout pour la représentation que ce soit UCS4 ou UTF-8.
            Ici, ça parle de représentation, donc d'Unicode, et on touche à NFD/NFC/NFD/NFKC.

            Bonne lecture somnifère :
            http://en.wikipedia.org/wiki/Unicode_equivalence#Example

            • [^] # Re: Pas que Git

              Posté par . Évalué à -3.

              Euh… là c'est plutôt toi qui est HS, car justement je questionne strictement ce qui est dit à propos du codage, pas sur ce qui touche la collision des représentations (à ce niveau, le conflit resterait le même en Latin1, mais ça ne m'interrogerait pas, ou pas de la même manière). Tu as le droit de supposer que flan a utilisé improprement le terme « UTF-8 » en voulant dire « Unicode », ça ne rend pas pour autant ma question HS (même si effectivement, c'est une piste de réponse).

              • [^] # Re: Pas que Git

                Posté par (page perso) . Évalué à 9. Dernière modification le 20/12/14 à 13:07.

                Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode, simplement parce que ça reste vrai : l'utilisateur tape un caractère « è », il est représenté dans le système de fichiers par de l'UTF-8 (ou de l'UTF-16/-32), même si la normalisation qui pose problème se fait au niveau de l'Unicode. Le conflit n'existe pas en Latin-1, parce qu'il n'y a qu'une seule façon de représenter le « è » (et qu'il n'y a pas d'histoire de normalisation NFKD/NFKC en amont).

                De plus, tant qu'on parle d'Unicode, les deux versions (« è » et « e + ` ») doivent être comparées comme étant égales par le logiciel. Par contre, quand elles sont encodées (en UTF-8) et que ça devient des séries d'octets, les deux versions sont différentes (Linux ne considère que des séries d'octets, sans prendre en compte que c'est de l'Unicode) et à ce moment là, on a un souci (deux fichiers avec un nom identique).

                Mais bon, c'est vrai que c'est totalement hors-sujet de parler UTF-8 au lieu d'Unicode, il n'y a strictement aucun lien entre les deux. Mea Culpa.

                • [^] # Re: Pas que Git

                  Posté par . Évalué à 2.

                  Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode

                  D'accord, je comprends mieux. Merci pour les précisions.

                  Le conflit n'existe pas en Latin-1

                  Techniquement, il pourrait, puisqu'au final ce n'est en fait pas une question de codage (on peut rendre les deux octets 101 et 96 ou bien le seul octet 232).

                  • [^] # Re: Pas que Git

                    Posté par (page perso) . Évalué à 2. Dernière modification le 20/12/14 à 15:45.

                    La code 96 est pour un signe indépendant.
                    Il n'y a pas de code en Latin-1 pour un signe dépendant, donc non, techniquement ce n'est pas possible, faute de code.
                    En Unicode, il y a un code pour le signe indépendant et un autre code pour le signe dépendant (lié à un autre code).

                    Le conflit n'existe pas en Latin-1, mais dans un codage que tu inventes de ton coté (non standardisé).

                    Note : ça ne serait pas idiot, mais à ma connaissance Latin-1 ne définit pas de dépendance avec un autre code.

                    • [^] # Re: Pas que Git

                      Posté par . Évalué à 2.

                      La code 96 est pour un signe indépendant.
                      Il n'y a pas de code en Latin-1 pour un signe dépendant, donc non, techniquement ce n'est pas possible, faute de code.

                      Ah oui, d'accord, là ça s'éclaire vraiment. En fait, j'avais à l'esprit le rendu (en sens inverse) qu'on obtient sur certains vieux logiciels quand ils doivent rendre du latin1 en ascii (où ê devient e^), mais on est dans une gamme de caractères dédiés (que du coup flan a rendu dans son premier commentaire avec le caractère 96 de l'ascii, ce qui m'a enduit d'erreur).

                      • [^] # Re: Pas que Git

                        Posté par (page perso) . Évalué à 3. Dernière modification le 20/12/14 à 16:59.

                        Ben oui, sinon tu ne le verrais pas ;-).
                        Pour continuer sur l'accent grave :
                        http://fr.wikipedia.org/wiki/Accent_grave

                        Tu vois pour 3 encodages unicode :
                        - le "legacy" 96 de l'ASCII.
                        - Les 2 différents codage Unicode "purs", d'un côté la lettre seule, de l'autre l'accompagnement (voir le rond en pointillé qui dit qu'il a besoin d'un autre code).

                        et suivant ton choix canonique, tu vas avoir 2 possibilité pour "è".
                        Je me permet de renvoyer sur mon premier commentaire :
                        http://en.wikipedia.org/wiki/Unicode_equivalence#Example
                        L'exemple te permet de voir les deux façons…

                        PS : est l'UTF-8 était toujours HS pour vous deux, HS dans le sens où ce n'est pas le sujet sur les deux formes Unicode qui pose problème ;-).

                        • [^] # Re: Pas que Git

                          Posté par . Évalué à 4.

                          Ben oui, sinon tu ne le verrais pas ;-).

                          Tout à fait, loin de moi l'idée d'en faire le reproche à flan.

                          PS : est l'UTF-8 était toujours HS pour vous deux, HS dans le sens où ce n'est pas le sujet sur les deux formes Unicode qui pose problème ;-).

                          Toujours pas. ;)

                          Un hors-sujet, c'est ce qui sort de l'énoncé du problème. Or, s'il avait effectivement existé un début de séquence UTF-8 magique permettant de « coller » deux ascii pour représenter un seul caractère (ce que je j'essaie de décrire dans mon premier message), on aurait bien eu deux codages possibles pour une même représentation, ce qui aurait été une bonne illustration du problème.

                          Pour être plus clair : si dans un devoir sur la respiration des cétacés tu traites (même savamment) de la reproduction des belettes en milieu péri-urbain, c'est un hors-sujet ; si tu commences par évoquer les branchies des baleines, c'est bien le sujet mais traité de manière absurde*. Dans les deux cas, on est d'accord que tu as tout faux (et pour ce qui est d'UTF-8, crois-moi j'en suis bien content), mais pas de la même manière.

                          * note que dans ce cas la question de savoir pourquoi alors les baleines sont obligées de remonter à la surface reste en elle-même pertinente, c'est juste une autre manière de gérer l'absurdité quand on est pas 100% sûr que c'en soit une mais qu'elle heurte ce qu'on croit savoir.

              • [^] # Re: Pas que Git

                Posté par (page perso) . Évalué à 0. Dernière modification le 20/12/14 à 13:08.

                Tu parles du codage UTF-8 d'un caractère Unicode, il parle de deux points Unicode pour écrire un caractère accentué (donc deux foix le codage UTF-8).
                donc vraiment, tu devrais te renseigner, car le codage UTF-8 n'est absolument pas changé (pas de "il faudrait avoir un octet spécial 111???? suivi par deux octets sur 7 bits 0???????"), ça reste de l'UTF-8 avec les règles classique d'UTF-8).

                Renseigne toi sur la différence codage UTF8 et représentation Unicode (j'ai même donné un liebn, et pour le reste Wikipedia n'est pas mauvais).

                car justement je questionne strictement ce qui est dit à propos du codage

                Codage au niveau Unicode ("e" Unicode + "`" Unicode = un caractère), pas comment il est stocké sur le disque (UTF-8). Que ce soit stocké en UTF-8 ou UTF-16 ou UCS4 ou toto ne change rien au sujet, et le codage UTF-8 n'est absolument pas modifié (pas de "il faudrait bla bla bla").

                ça ne rend pas pour autant ma question HS

                Je n'ai jamais dit que ta question est HS, seulement que parler du codage UTF-8 comme tu l'a fait est HS (pas le bon niveau).


                Après, si tu ne veux pas chercher à comprendre et penser que je suis HS, ben j'abandonne, reste avec tes idées fausses sur Unicode et UTF-8, le monde continuera à vivre avec des gens ayant des idées fausses dessus, un de plus ou de moins ne changera pas grand chose.

                • [^] # Re: Pas que Git

                  Posté par . Évalué à 3.

                  Tu parles du codage UTF-8 d'un caractère Unicode, il parle de deux points Unicode pour écrire un caractère accentué (donc deux foix le codage UTF-8).

                  Au final oui, mais dans son message initial, il a bien parlé d'UTF-8, ce qui m'a surpris par rapport à ce que je sais de cet encodage. Or, je ne prétends pas tout savoir, d'où ma demande de précisions au cas où j'aurais pu apprendre quelque chose.

                  Je n'ai jamais dit que ta question est HS

                  Excuse-moi, mais « Vous » dans un fil d'exactement deux messages, ça désigne les auteurs des deux messages. Tu aurais simplement pu dire « je crois qu'en fait il veut parler de points de code et pas d'octets », pas besoin de rentrer dans les gens en affirmant direct qu'ils ne disent pas ce qu'ils sont précisément en train de dire (un peu comme si moi j'avais commencé mon commentaire à flan par « c'est vraiment n'importe quoi ce que tu dis sur UTF-8, … » – mais, ça aussi, c'est pas comme si les gens ne t'avaient jamais fait remarquer cette attitude, mieux vaut donc lâcher définitivement l'affaire pour ce qui te concerne du point du vue de la convivialité).

        • [^] # Re: Pas que Git

          Posté par . Évalué à -2. Dernière modification le 22/12/14 à 03:23.

          En meme temps, git est utilise par plein de projet, mais il a ete cree pour un projet bien precis… linux et la curieusement il n'y a pas de probleme car le systeme de fichier n'est pas reste aux annees 80 pour la gestion de noms.

          • [^] # Re: Pas que Git

            Posté par (page perso) . Évalué à 1.

            il n'y a pas de probleme car le systeme de fichier n'est pas reste aux annees 80 pour la gestion de noms.

            Le soucis, ce n'est pas ça. Ce n'est pas la gestion des noms qui est antédiluvienne, mais le choix d'une propriété d'un système de fichiers qui pose problème : sensible ou insensible à la casse. Et en réalité, ce n'est même pas le choix qui pose le soucis, mais la cohabitation de systèmes de fichiers aux propriétés différentes.

            • [^] # Re: Pas que Git

              Posté par . Évalué à 1.

              Le raccourcissement des noms c'est pas année 80?

              • [^] # Re: Pas que Git

                Posté par (page perso) . Évalué à 1.

                être compatible = être dépassé ?

              • [^] # Re: Pas que Git

                Posté par (page perso) . Évalué à 1.

                Le raccourcissement des noms c'est pas année 80?

                Et pour être précis, c'est les années 90. 94 pour être précis ;)

              • [^] # Re: Pas que Git

                Posté par . Évalué à 2.

                Le raccourcissement des noms c'est pas année 80?

                Et la rétrocompatibilité, pour toi aussi c'est propre aux années '80 ?!

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Pas que Git

                  Posté par (page perso) . Évalué à 3.

                  Si faut se faire chier pour que git (nan mais git quoi, pas CVS) fonctionne sous Windows 98, je me torche avec la compatibilité.

                  • [^] # Re: Pas que Git

                    Posté par . Évalué à 3.

                    Rien à voir.

                    NTFS fournit toujours des noms courts pour les anciennes applications, c'est tout. Ca coûte 0$ à Microsoft, et ça permet à pas mal d'applications que les utilisateurs VEULENT voir fonctionner, fonctionner.

                    Faire en sorte que git tourne sous Windows 98 ne serait pas une histoire de bug/feature gardé pour des raisons de rétrocompatibilité, mais un port de git. Rien à voir, et totalement HS, donc.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Pas que Git

                      Posté par (page perso) . Évalué à 3.

                      NTFS fournit toujours des noms courts pour les anciennes applications, c'est tout. Ca coûte 0$ à Microsoft, et ça permet à pas mal d'applications que les utilisateurs VEULENT voir fonctionner, fonctionner.

                      Ouais et donc je vois pas bien le rapport. git utilise des API de compatibilité antédiluviennes et s'attend à des noms 8.3 ? Ou alors c'est pour qu'un projet cloné via git soit éditable avec le wordpad W98 que tu lancerais en mode compatibilité sur un W7+ pour le lulz (auquel cas je modifie mon premier message : si c'est pour pouvoir coder avec un éditeur datant de W98, je m'en torche) ?

                      • [^] # Re: Pas que Git

                        Posté par . Évalué à 3.

                        Ouais et donc je vois pas bien le rapport. git utilise des API de compatibilité antédiluviennes et s'attend à des noms 8.3 ?

                        Si je comprends bien "check for Windows shortname aliases" (je trouve rien de plus détaillé) le problème était que les chemins 8.3 étaient considérés des chemins différents que la version longue, alors que c'est juste un alias.

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Pas que Git

        Posté par (page perso) . Évalué à 7.

        Il y a une petite flopée d'autre transformation faite sous windows, par example les "." en fin de fichier ("toto." → "toto") et les espaces en début de fichier (" toto" → "toto"). Cette catégorie de blague était déjà géré par Mercurial.

        Les nouveautés sont l'exploitation des nom courts (suggérée par quelqu'un de chez Microsoft, quand ils ont été informés de la CVE) et la faille sur les caractères Unicode ignorés par Mac os X (trouvée par Matt Mackall pendant une longue soirée d'hiver.)

  • # Sur mac os x

    Posté par . Évalué à 7.

    Sur mac os x, le git livré par Apple est vulnérable et à cette heure, ils ne proposent pas de mise à jour.
    Problème réglé rapidement si vous utilisez http://brew.sh/

    $ brew update && brew install git 
    
    $ git --version
    git version 2.2.1
    # Les autres versions patchées sont v1.8.5.6, v1.9.5, v2.0.5, v2.1.4 et v2.2.1 

    Si vous avez mal configuré votre PATH, vous utiliserez la version vulnérable

    $ /usr/bin/git --version
    git version 1.9.3 (Apple Git-50)

    Pour des logiciels qui utilisent git en interne (style github.app, sourcetree, android studio, …), vérifiez dans leurs préférences qu'ils utilisent la version de git du système

  • # Notion bizarre

    Posté par . Évalué à 9.

    La solution pour une interopérabilité maximale est de se réduire au plus petit sous-ensemble commun […]

    Ne serait-ce pas, ce qui me semblerait plus logique, plutôt le plus grand sous-ensemble commun à tous les systèmes ? Ça me fait penser à cette expression si répandue chez les plumitifs et qui ne veut pas dire grand-chose : le plus petit diviseur commun.

    Je ne parle pas pour toi qui a dû faire un lapsus, mais pour la notion fallacieuse de plus petit diviseur commun, il serait bon que certains revoient l'arithmétique élémentaire.

    • [^] # Re: Notion bizarre

      Posté par . Évalué à 4.

      C'est juste parce qu'ils sont payés au mot ou au caractère les plumitifs. "un" ca ne nourrit pas son homme

    • [^] # Re: Notion bizarre

      Posté par (page perso) . Évalué à 2. Dernière modification le 20/12/14 à 02:11.

      Tu as effectivement raison, il faut bien lire le plus grand sous-ensemble commun (ou pour faire plus simple, l'intersection).

      Sinon tu m'as fait découvrir le mot plumitif, je vais le garder sous le coude pour des utilisations futures.

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # Est-ce vraiment une vulnérabilité de git ?

    Posté par . Évalué à 3.

    J'ai plutôt l'impression que git fait simplement son travail… et pas celui du système de fichier. Cela fait des années que l'ont peut utiliser cette manière de faire avec quantité de langage…

    Le problème ne vient pas de git, mais du système de fichier qui ne fait pas la différence entre deux noms de fichiers qui sont différents.

    • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

      Posté par . Évalué à 6.

      Le problème ne vient pas de git, mais du système de fichier qui ne fait pas la différence entre deux noms de fichiers qui sont différents.

      Non, le problème vient de git qui suppose que 2 fichiers avec une case differente sont des fichiers differents, alors que ca n'est pas le cas avec tous les système de fichier. Et il n'y a aucune regle qui dit que ca doit etre le cas.

      • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

        Posté par (page perso) . Évalué à 3. Dernière modification le 20/12/14 à 23:16.

        Non, le problème vient de git qui suppose que 2 fichiers avec une case differente sont des fichiers differents, alors que ca n'est pas le cas avec tous les système de fichier. Et il n'y a aucune regle qui dit que ca doit etre le cas.

        Si git supposait que 2 fichiers avec une casse différente sont de fichiers identiques, alors on pourrait dire aussi que c'est de sa faute car ce n'est pas le cas avec tous les systèmes de fichiers.

        Et j'ai du mal à imaginer une option de configuration par exemple, vu ce qui git est : un gestionnaire de version. Si A utilise du Ext4, B peut utiliser du NTFS. Bref, j'ai l'impression que le problème est au-delà de git : c'est une limitation des gestionnaires de version.

        [edit]
        En fait, il faudrait forcer la casse. Par exemple, tout en minuscule. Et si on est sur un système de fichier qui est sensible à la casse et que 2 fichiers sont identiques à la casse près, alors on génère une erreur
        [/edit]

        • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

          Posté par . Évalué à 1.

          Si git supposait que 2 fichiers avec une casse différente sont de fichiers identiques, alors on pourrait dire aussi que c'est de sa faute car ce n'est pas le cas avec tous les systèmes de fichiers.

          Le client git est spécifique à un OS, il est sensé suivre les conventions de celui-ci, et c'est à lui de protèger le système du client d'un serveur qui enverrait qqe chose de malicieux, aussi simple que ça.

          • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

            Posté par (page perso) . Évalué à 3.

            Le client git est spécifique à un OS, il est sensé suivre les conventions de celui-ci, et c'est à lui de protèger le système du client d'un serveur qui enverrait qqe chose de malicieux, aussi simple que ça.

            Sauf que la on ne parle pas d'OS, mais de système de fichiers. Et comme on est sur linuxfr, je vais prendre l'exemple de linux : avec les jeux de montages et compagnies, on peut très bien travailler sur de l'Ext2,3,4, NTFS, vfat, et je passe les systèmes de fichiers réseau (NFS, CIFS, etc…).

            Bref, c'est loin d'être aussi simple…

            • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

              Posté par (page perso) . Évalué à 5.

              En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
              Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
              D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
              Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.

              • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

                Posté par (page perso) . Évalué à 4.

                Attention de ne pas mélanger les problèmes d'encodages avec ceux de collisions (qui est justement le sujet de cette dépêche) ;) Je me trompe peut être mais j'ai l'impression que ce n'est pas très clair…

                Les problèmes d'encodages, c'est effectivement au logiciel de gérer cela. C'est son rôle. Les problèmes de collisions dont il est question ne sont pas inhérent au logiciel lui-même, mais au système de fichiers sous-jacent utilisé.

                J'ai l'impression que pour éviter cela, il faudrait que le gestionnaire de version "impose" des règles, ce qui va à l'encontre de la conception que je m'en fais (mais là, c'est un avis personnel). Pour moi, il doit être non intrusif sur la manière de développer (je dis "développer" car cela reste l'usage principal) et donc sur la manière de nommer les fichiers. Et donc j'ai du mal à lui reprocher des limitations dûes aux propriétés du système de fichier sous-jacent. Si je fais un git clone sur du FAT16, je ne m'attends pas à des miracles… mais je ne remets pas en cause git pour autant…

              • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

                Posté par (page perso) . Évalué à 3.

                Et comment tu fais du Java avec tout en bas-de-casse? Hein? :D

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

                  Posté par . Évalué à 2.

                  J'ai un peu du mal à comprendre. Pourquoi est ce que le nom réél du fichier ne pourrait pas être une méta-donnée comme une autre ?

                  Exemple : soit le système A case sensitive, et un système B, cas insensitive, ainsi que deux fichiers TRUC et truc.

                  Système A :

                  • nom de fichier affiché dans le système de fichier : TRUC
                  • nom de fichier connu par le gestionnaire de version : TRUC

                  • nom de fichier affiché dans le système de fichier : truc

                  • nom de fichier connu par le gestionnaire de version : truc

                  Système B :
                  - nom de fichier affiché dans le système de fichier : truc~1
                  - nom de fichier connu par le gestionnaire de version : TRUC

                  • nom de fichier affiché dans le système de fichier : truc~2
                  • nom de fichier connu par le gestionnaire de version : truc

                  bépo powered

                  • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

                    Posté par (page perso) . Évalué à 2.

                    Ça m’a l’air bien complexe ton bazar. Je ne dis pas que c’est possible, je montrais juste un exemple du type de problème qu’on peut avoir simplement en imposant les minuscules dans les noms de fichiers.

                    Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Est-ce vraiment une vulnérabilité de git ?

                    Posté par (page perso) . Évalué à 2.

                    C'est à peu près comme ça que ça marche. Mais le gestionnaire de versions doit quand même être capable de faire l'association entre le nom qu'il connait et celui de gestionnaire de fichiers. Par exemple, "git status" liste le contenu d'un répertoire, il obtient truc~1 et truc~2, il regarde ce qu'il connait (truc et TRUC), et il faut qu'il t'affiche la liste des fichiers non trackés en faisant la différence entre ces deux listes. Ça a été la source d'un bug de Git sous Mac OS X qui a mis bien longtemps à être corrigé (core.precomposeunicode).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.