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

Comments

I blame Microsoft

[Anonymous Coward]

For creating case-insensitive file systems.

What.

The.

Fuck.

Re:I blame Microsoft

[pushing-robot]

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.

Re:I blame Microsoft

[Dutch Gun]

Karma be damned...

One could alternately argue: do you feel it's a good thing for something.dat and Something.dat to reference two different files? Because that would never confuse users, right? Shall we next talk about forward slash versus backslash in path separators, and how one is obviously much more logical and intuitive than the other? Or maybe we should get into line endings, or perhaps how there really shouldn't be any distinction between text and binary files? UTF-8 vs UTF-16?

Newsflash: different operating systems have different conventions and different quirks. I'm going to take a wild-ass guess and predict that you believe the choices of your preferred OS are obviously the correct choices.

Re:I blame Microsoft

[by (1706743)]

An AC above somewhere (comment: "polish != Polish") had a great comment: there's a difference between the filesystem and the UI. If a UI (file manager, shell, etc.) wants to reference two different files in a different fashion, fine. But the filesystem "should give back exactly what was put into it (both in terms of files and data)."

Re:polish != Polish

[Dutch Gun]

You know, one could argue that case sensitivity in file systems actually demonstrates the difference between the *nix vs. Windows philosophies pretty well. Disclaimer: I'm a Windows guy, so let me know if I'm making unfair characterizations.

*nix

*nix is about power, flexibility, and user control. It favors command-line interaction through discrete commands, applications, and scripts. This makes it extremely suitable for power-users and administrators who are willing to invest the time to become proficient in using these tools. Visual interfaces are often built on top of these command-line actions, which can create a slightly disjointed experience for more casual users who don't understand what's happening under the hood or can't easily fall back to command-line use when needed.

File system design: A file system should give back exactly what was put into. We should provide maximum flexibility and utility, even if it comes at the expensive of user-friendliness. The entire system should not be dumbed down to protect users who can't even figure out how to properly name their files, because there may be legitimate use cases for case sensitivity in file naming.

Windows

Windows is about user-friendliness. Visual tasks and interactions are emphasized over command-line actions. Applications are often extended through proprietary extensions or internal scripting rather than through command-line input and output. Because the system is build with visual interaction in mind first and foremost, users never have to interact with a command-line. This makes it easier for casual users to achieve faster results with less training, but can come at the cost of a more shallow understanding of their computers (e.g. if the visuals change significantly, users may become confused).

Filesystem design: We can't really think of a reasonable use case in which a user would actually want to create two different files in the same directory that only differ by case. In reality, it would probably be the result of an mistake, and this may cause confusion for users. Therefore, we'll just restrict the functionality to eliminate that potential error. We're willing to write a bit of extra code to preserve case but to discard it when disambiguating files.

Re:Case insensitive file systems were a bug

[aardvarkjoe]

A quick glance at that article seems more like a compelling case for teaching people how to write shell scripts properly.

If you read the article, you'll find that writing shell scripts to handle filenames containing every possible character "properly" is so difficult that virtually everyone gets it wrong. When something's been around for close to 40 years and still nobody can get it right, maybe it's time to admit that it's the tool that's broken.