21–30 of 228 posts
Earlier quoted context omitted.
MacOS and Windows
I guess it shows that I haven't really used either of those in a long time.
Earlier quoted context omitted.
macOS, to name one. It appears NTFS is also vulnerable according to the posting.
Ashamed to admit (as an OSX user) that I didn't even realize the FS was case-insensitive (having migrated from years of Linux usage to a non-Linux desktop). It does a good job of hiding this from the user (filenames are still listed with cases, and bash autocompletion completes to the correct case as well)
Many fun times trying to copy/move/remove a file and not being able to do so because the input and name stored on fs is actually different bytewise...
Seems like linux has the only sane filesystems not trying to mangle paths at all.
The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?
macOS, to name one. It appears NTFS is also vulnerable according to the posting.
Earlier quoted context omitted.
Ashamed to admit (as an OSX user) that I didn't even realize the FS was case-insensitive (having migrated from years of Linux usage to a non-Linux desktop). It does a good job of hiding this from the user (filenames are still listed with cases, and bash autocompletion completes to the correct case as well)
MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.
Nah. Using a file system means putting up with its semantics. HFS+ was case-insensitive; they were deploying an upgrade to millions of existing filesystems.
If you mount, say, an NFS volume, MacOS does the expected thing.
Earlier quoted context omitted.
Ashamed to admit (as an OSX user) that I didn't even realize the FS was case-insensitive (having migrated from years of Linux usage to a non-Linux desktop). It does a good job of hiding this from the user (filenames are still listed with cases, and bash autocompletion completes to the correct case as well)
MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.
This should be fixed especially for those who want to inspect the code in a repository before running it. But anyone should keep in mind that malicious repositories can do a lot of bad things after cloning, even without this bug.
> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?
Windows. Its a notable problem with git + Windows that has gotten better over time but still leads to a lot of WTF moments. For many this event is the first time they hear that window's filesystem is case insensitive.
The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
(1) cache invalidation
(2) off-by-one errors