Can we get the title changed to "on macOS and Windows?"
I was worried for a second, but this is meaningless.
Of course, you should still update because you're a config change away from being vulnerable, but GP's point of it not being a big deal if (and only if, don't know if that's correct) nobody uses it stands.
Seems like a weird edge case to me. I guess Apple and Microsoft should push out OS updates to cover it.
That said, I did snicker at the comment :) I had no idea it was that old.
The "junctions" are unusable as "windows symlinks".
For one, you can't create any as a normal non-admin user without specific authorization by default.
I don't think this is true at all. Too many things will break if you turn this on.
I've actually thought about converting my whole $HOME to that way, but I do have a few files that would conflict if I did that. I honestly don't think it's that bad of an idea.
There's also the possibility of a git repo on a SMB share. That's not a use case I have, but it's not too difficult to imagine in a corporate environment.
Case sensitivity is one of the things that really bothers me on Linux, it causes me to make mistakes for no reason. If I ever really switched to Linux full-time, I’d probably want to change that.
Case sensitivity wasn’t designed; the first Unix couldn’t spare the CPU cycles to do case insensitive matching, which was the norm at the time.
Don't you think that 65 ≠ 97 is sufficient of a reason?..
I mean, 'A' ≠ 'a', in ASCII, Unicode and even EBCDIC. In computers, those are two distinct characters. This fact won't change no matter how you rationalize your expectations.
Thus, pretending that "y.txt" is the same as "Y.txt" is an elaborate lie. Even acknowledging that it's a "white", well-intentioned lie (designed to preserve the mistaken expectation that "y.txt" is the same as "Y.txt") — I don't like when computers lie to me; do you?
As every lie, this one has weird consequences. One of them is the today's RCE in OP. Another one was CVE-2014-9390. Myriads others.
Linux rejects the whole notion of filename case-insensitivity, and demonstrates how computers actually work. It becomes easier on developers and more secure on users.
Lastly, don't feel that I'm attacking you; I'm opposing an idea. So, here's a tip: you can set up case-insensitive filename completion in bash, so that TAB will correct your casing mistakes for you. It's a simply one-line change involving putting `set completion-ignore-case on` into an inputrc.
In computers yes, but i am a human and to me as a human 'A' and 'a' are the same letter.
We do have the options to ignore the fact and say "What bytes? I don't care. Guess what I mean, and lie to me as well as you can so I can stay happy in my ignorance" — but, see, coordinating good support for that isn't easy. Minor wrinkles in it continue causing burns, sometimes RCEs. Maybe "doing in Rome as Romans do" isn't such a bad advice after all?
It's almost comical: people continue insisting on "letters not code points" knowing very well how computers are bad with guesswork and under-defined notions. Issues stemming from that keep coming up. What if, instead, the norm accepted that 'A' ≠ 'a' and stopped creating problems which computers are known to deal poorly with?
65 ≠ 'A'.
Anyway, what I'm actually thinking when something like this is disclosed is how many more similar things must be known to a team of malicious professionals at Unit 8200 or whatever. I don't think I would reasonably suspect "git clone" being capable of something like that. How many more things I don't suspect to be dangerous actually are? It feels almost pointless to worry about it.
That isn't correct; it's a bug that manifests on case-insensitive[1] filesystems.
My colleagues who run a linux VM (our product targets Linux only) tend to git-clone onto a mounted NTFS partition so they can access the source from both host and guest. This bug will affect them even though they are running on Linux.
My other colleagues who run an actual Linux box tend to use a fast removable drive to git-clone (so they can work on it from home), and said drives tend to be FAT, which will also be susceptible to this bug.
If, on the third hand, you're running Windows and using ext4 as a filesystem (removable drive, mounted partition, whatever), then this bug should not affect you.
TLDR; the OS doesn't matter, the filesystem does.
[1] They aren't, not really; NTFS is case-sensitive! It preserves the case when writing filenames and ignores it when reading filenames.