Live data from Hacker News

Git client vulnerability announced

github.com

181–190 of 191 posts

Re: Git client vulnerability announced

#181

I think here is a good argument for not using case-insensitive filesystems - because every single filename comparison gets affected and it can lead to vulnerabilities like this (I wonder what others are out there...) Case-insensitive initially feels like a good idea to some, but I think it's a good example of "trying to do too much" and often in subtle ways that even the user might not fully understand - the definiti…

The issue here is not case-insensitive filesystems, they are a huge benefit to novice users. But that the type system does not distinguish between paths and strings. A path is distinctly different from a string, and should never be compared as one. The type system should always enforce this and never allow you to mistakingly do the comparison you propose, for exactly the reasons you state. Modern filesystem libraries…

As you point out, a path is different from a string. It makes sense in many cases to do a case-insensitive comparison on strings. It NEVER makes sense to do that on paths.

A path is an identifier. Just as it's infuriating and horrendous to have programming language identifiers act case-insensitively, it's a poor design choice to have path identifiers act case-insensitively.

I suspect that what you describe as a huge benefit to novice users is entirely seen in search functionality, where you are comparing a string (the search needle) against a number of paths (the haystack). Since this search should be conducted by converting the path to a string (never the other way around, that's nonsensical) it's perfectly natural to support CI operations on strings but forbid them on paths.

Re: Git client vulnerability announced

#184
post #180

Earlier quoted context omitted.

World of Warcraft (and any other Blizzard game) won't run off of a case sensitive filesystem.

Steam also requires case-insensitive filesystem on OSX.

Steam on Linux does not. That probably means that Linux doesn't get any steam games that require a case-insensitive fs even if they would work otherwise (unity3d, monogame, ...), at least if there isn't a special linux version that does not require it.

I never really thought about this issue.

Re: Git client vulnerability announced

#185

Earlier quoted context omitted.

http://en.m.wikipedia.org/wiki/Unicode_equivalence http://en.m.wikipedia.org/wiki/IDN_homograph_attack What seems really scary about this is that even Unicode has several different ways of comparing strings, and the correct one depends on the exact situation, so the common response of "just use a library" doesn't work; for example, if a user were searching for a filename it might make sense for full-width characters…

I don't understand. Why can't a library just compare strings at the code-point level, ignoring "canonical equivalence"?

Then you run into problems with how characters are represented. For instance, é (lowercase latin e with an acute accent) can be represented either by one unicode codepoint (U+00E9, 'LATIN SMALL LETTER E WITH ACUTE'), or by two unicode codepoints (U+0065 U+0301 -- LATIN SMALL LETTER E, COMBINING ACUTE ACCENT). There are normalization forms that will convert these two representations into the same representation for easier comparison.

If you don't perform canonical equivalence checking, you could search for "café" and not find a file named "café.txt" if it uses the other representation.

Re: Git client vulnerability announced

#186

Short panic summary: your git/hg remotes can get code execution on your machine when you clone/pull if you are on OSX or Windows. Summary: on case-insensitive/normalizing filesystems (default on OSX and Windows) it's possible for .git/config to be overwritten by the tree, probably due to a case-sensitive sanity check when the actual file is insensitive. .git/config can contain arbitrary commands to be run on certain…

Hmm. I have git 2.2.0 installed through Homebrew, but the Homebrew repo seems broken at the moment? edit: Nevermind, short-lived issue. Just upgraded to 2.2.1.

For anyone looking to update via Homebrew, make sure it has the latest formulae:

  brew update
  brew upgrade git

Re: Git client vulnerability announced

#187

Earlier quoted context omitted.

And the case-sensitivity stuff is somewhat low-hanging fruit, but... On Windows, certain path components that are different from ".git" are mapped to ".git", e.g. "git~1/config" is treated as if it were ".git/config". HFS+ has a similar issue, where certain unicode codepoints are ignored, e.g. ".g\u200cit/config" is treated as if it were ".git/config" So that's what ridiculous means. Huh.

Oh my lord. That's just Windows being vulnerable, rather than git though, right? No way every piece of Windows software protects adequately against that ... misfeature.

There's been half a dozen path traversing exploits against MS IIS, before they finally caved in and took reasonably complete measures in IIS 6 (IIRC).

Re: Git client vulnerability announced

#189
post #126

Earlier quoted context omitted.

Apple has updated this in Xcode 6.2 beta 3: http://support.apple.com/en-us/HT204147

Seems like the Command Line Tools (without XCode), which also ships git, have not been updated (yet). Rather annoying.

I'm with you. I was really hoping today we'd see a fix in the Command Line Tools and existing XCode versions. How is Apple including the fix only in the next version (beta) a sufficient response?

Re: Git client vulnerability announced

#190

Earlier quoted context omitted.

And the case-sensitivity stuff is somewhat low-hanging fruit, but... On Windows, certain path components that are different from ".git" are mapped to ".git", e.g. "git~1/config" is treated as if it were ".git/config". HFS+ has a similar issue, where certain unicode codepoints are ignored, e.g. ".g\u200cit/config" is treated as if it were ".git/config" So that's what ridiculous means. Huh.

Oh my lord. That's just Windows being vulnerable, rather than git though, right? No way every piece of Windows software protects adequately against that ... misfeature.

Nah. From a purist POV, you can sneer at this and say "Bah! Case-insensitive filesystems in 201X? I save `CAT` and that replaces `cat`? Save me, mighty failcats! Wherever else in CS do we accept such blatant approximations, instead of The One And Actual True Computational Result". And you would be mostly right (except for anything floating point).

The reality check is that neither Windows nor MacOS ambushed anyone with overnight with case-insensitivity. It's been there (as the default, right?), since "forever". Git officially supports Win & Mac. Git design already protected .git/config, just not in a sufficiently effective manner (as far as 2/3ds of their major distribution platforms are concerned - yes, the defaults are what you should assume everyone has). [1]

Fun estimate: A lot of technical/knowledgable MacOSX folks, especially in the Webdev/webdesign/etc industries, will have been vulnerable to this despite their personal preferences. Adobe Photoshop (and the others of the creative suite, I think) had a certain idiosyncratic behaviour[2] when certain conditions were not met[3]. You paid thousands for that broken installer/support and Richard Stallman weeps for you.

[1] Aside: You think Git is getting shafted by Windows/Mac implementation idiosyncrasies in this case? Then you'll love the favourite issue node.js on windows: "Breaks on large projects". This is essentially a side-effect of solving the dependency hell problem effectively - by nesting dependencies under a node_modules directory on both project and dependency levels - and insufficient intelligence to foresee that preserving path length is a viable goal in software design (in 200X, no less). Because, in sufficiently bloated projects, you can have enough nested node_modules/$name/node_..., that you literally blow Windows' fuse. But it's not a big deal, because that max path length is like some huge number, like 2^32 or some shit. Righ - 260 characters. 257 and C:\. Including slashes and all. So when node.js picked the completely reasonable "node_modules" as a dependency includes dir name, they should have known better - that their project would attract a huge audience and that sufficiently complicated/bloated packages would be created and distributed that their depencency-includes-dir-name selection would become a show-stopper, because one of our favourite OSes is still eating glue in the corner. And what didn't actually work? Not node. Not npm. Windows Explorer and other tools/utils that weren't updated to support NTFS' actual maximum path size - 32K. On the one hand, node.js github issues piling up ("FIXITTT!!!!") and on the other, Microsoft says "NTFS supporting 32K path length, while Windows Explorer supporting 260 chars, is not a bug. Repeat, not a bug."

[2] Didn't work at all. "It isn't a bug, it's a System Requirement."

[3] Case-insensitivity in the FS. Not just as a concept, but as a pre-requisite for installing an expensive class-A consumer design application. Really think about this. You've just paid between 3 and 4 digit sums for this single license. The installer creates a bunch of files, but for securitah(?) we randomize capitalization of all paths (!) so the only way this could possibly work is if the god damned filesystem is cool with the app sometimes requesting 'Data', others 'data', occasiionally (during rants, mostly) 'DATA', and every April Fools day, 'dAtA', and always getting back the (proper) 'daTA'. As a developer, isn't this about as desirable as trying to save "C:\programs I should delete.txt" and receiving a "C:\progra~2.txt" path in return? What the unholy fuck? I asked for a very specfic filename. Either error me outta here ('Sorry Dave, I can't do space') or do exactly as I said.

[4] No, you're drun.

Post reply on HN