Slashdot Mirror
Critical Git Security Vulnerability Announced
An anonymous reader writes Github has announced a security vulnerability and has encouraged users to update their Git clients as soon as possible. The blog post reads in part: "A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows and GitHub for Mac. Because this is a client-side only vulnerability, github.com and GitHub Enterprise are not directly affected. The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem....Updated versions of GitHub for Windows and GitHub for Mac are available for immediate download, and both contain the security fix on the Desktop application itself and on the bundled version of the Git command-line client."
...are the dumbest thing ever.
The headline is wrong too. This isn't a Git vulnerability. This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names. That Git has a workaround for their broken behavior is good in the short run, but the correct solution would be to fix Windows and Mac OS X so that they can tell the difference between upper and lowercase letters.
You are clear that there's a standard for what makes a "computer file system interface" (it's part of POSIX) and it's quite clear that file systems should be case sensitive. So, yes, this is a Windows and Mac OS X bug, and not a Git bug. If they were proper operating systems, this wouldn't be an issue.
Yeah, what's next? Case-insensitive email addresses and domain names?
Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.
You are conflating two things that are (or should be) separate: the file system and the UI.
The file system (paths and names) should be case sensitive. If I give the VFS a string of bits that represents a file's name (regardless of ASCII, Unicode, or EBCDIC) it should take those bits and store them as-is and give them back as-is with interpreting them.
The UI (whether the GUI or maybe the CLI shell) could then make things easier for humans by treating "p" like "P", but the file system should treat them differently.
There is a difference after all between "Polish metal" (geographic connotations) and "polish metal" (to make shiny). Or, as another example, the sentences "I helped my Uncle Jack off a horse" and "I helped my uncle jack off a horse". If you want to have your GUI/CLI treat them the same, go ahead (just set your $LC_COLLATE appropriately), but don't bake that shit into the VFS or FS.
HFS+ switched from Unicode 2.1 to 3.2 decomposition/normalization a few years back which caused issues for git:
http://marc.info/?l=git&m=120104708602274&w=3
Really: a file system should give back exactly what was put into it (both in terms of files and data).