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.
Aller plus loin
- Annonce de Github (157 clics)
- Annonce du correctif Git (124 clics)
- Annonce du correctif Mercurial (41 clics)
- Référence CVE-2014-9390 (49 clics)
# Linux power!
Posté par alpha_one_x86 (site web personnel) . É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 feth . É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 cortex62 . Évalué à -6.
ah oui ? lequel ? c'est une question ;-)
[^] # Re: Linux power!
Posté par wismerhill . Évalué à 5.
Ils sont cités dans la dépêche.
[^] # Re: Linux power!
Posté par zurvan . É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…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Linux power!
Posté par feth . É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 zurvan . Évalué à 0.
oui ça peut arriver. De toute façon on peut s'attendre à tout en utilisant fat32 / ntfs
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Linux power!
Posté par pasBill pasGates . É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 zurvan . É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 ?
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Linux power!
Posté par pasBill pasGates . É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 Zenitram (site web personnel) . Évalué à -4.
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 rewind (Mastodon) . Évalué à 9.
tU pEnSeS vRaImEnT qUe Ça Ne FaIs AuCuNe DiFféReNcE, zEnItRaM ?
[^] # Re: Linux power!
Posté par groumly . Évalué à 1.
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 Krunch (site web personnel) . É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 groumly . É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 Zenitram (site web personnel) . É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 barmic . Évalué à 9.
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 ymorin . Évalué à 9.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 8.
Je pense que Menton faisait référence à la ville, donc son exemple est pertinent.
[^] # Re: Linux power!
Posté par barmic . É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 Krunch (site web personnel) . Évalué à 2.
Ou d'ExpertsExchange.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Linux power!
Posté par whity . Évalué à 6.
Ç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 flan (site web personnel) . É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 Antoine . Évalué à 4.
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 whity . É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 Antoine . É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 pasBill pasGates . É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 zurvan . Évalué à 1.
"it's not a bug, it's a feature!"
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Linux power!
Posté par Antoine . É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 pasBill pasGates . É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 Anonyme . Évalué à -3.
Il voulait surement savoir lequels sous Linux!
[^] # Re: Linux power!
Posté par Yth (Mastodon) . Évalué à 6.
Ben les trois fonctionnent sous Linux…
Yth.
[^] # Re: Linux power!
Posté par Anonyme . Évalué à 1.
j'ai oublier : pour une installation
# Pas que Git
Posté par Sébastien Douche . É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 RoM1 . Évalué à 10. Dernière modification le 19 décembre 2014 à 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 Benoît Sibaud (site web personnel) . Évalué à 3.
Merci pour les précisions, qui ont été ajoutées à la dépêche.
[^] # Re: Pas que Git
Posté par flan (site web personnel) . É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 Ignatz Ledebur . Évalué à 1.
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 Zenitram (site web personnel) . É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 Ignatz Ledebur . É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 flan (site web personnel) . Évalué à 9. Dernière modification le 20 décembre 2014 à 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 Ignatz Ledebur . Évalué à 2.
D'accord, je comprends mieux. Merci pour les précisions.
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 Zenitram (site web personnel) . Évalué à 2. Dernière modification le 20 décembre 2014 à 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 Ignatz Ledebur . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 3. Dernière modification le 20 décembre 2014 à 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 Ignatz Ledebur . Évalué à 4.
Tout à fait, loin de moi l'idée d'en faire le reproche à flan.
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 Zenitram (site web personnel) . Évalué à 0. Dernière modification le 20 décembre 2014 à 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).
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").
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 Ignatz Ledebur . Évalué à 3.
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.
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 Albert_ . Évalué à -2. Dernière modification le 22 décembre 2014 à 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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pas que Git
Posté par Albert_ . Évalué à 1.
Le raccourcissement des noms c'est pas année 80?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pas que Git
Posté par xcomcmdr . Évalué à 2.
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 Sufflope (site web personnel) . É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 xcomcmdr . É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 Sufflope (site web personnel) . É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 ? 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 xcomcmdr . Évalué à 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 marmoute (site web personnel) . É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 jean-michel.bertrou.eu . É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/
Si vous avez mal configuré votre PATH, vous utiliserez la version vulnérable
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
[^] # Re: Sur mac os x
Posté par Xinfe (site web personnel) . Évalué à 1.
Pour info, l'exécutable est installé par homebrew là :
/usr/local/bin/git# Notion bizarre
Posté par Philip Marlowe . Évalué à 9.
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 mazarini . É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 erdnaxeli (site web personnel) . Évalué à 2. Dernière modification le 20 décembre 2014 à 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.
[^] # Re: Notion bizarre
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Est-ce vraiment une vulnérabilité de git ?
Posté par Egide Dey . É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 Anonyme . Évalué à 6.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 20 décembre 2014 à 23:16.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par pasBill pasGates . Évalué à 1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par pulkomandy (site web personnel, Mastodon) . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par ariasuni . É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 robin . É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 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
bépo powered
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par ariasuni . É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 Matthieu Moy (site web personnel) . É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).
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par robin . Évalué à 1.
Merci pour les explications.
bépo powered
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.