11–20 of 228 posts
> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?
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.
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)
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)
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)
> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?
https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...
Note: I also learned this today. Had no clue.
https://github.com/gitster/git/commit/684dd4c2b414bcf648505e...
(Surprise, the root cause is a cache)
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.
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.
EDIT: This document describes some of the challenges: https://www.usenix.org/legacy/publications/library/proceedin...
> if Git is configured globally to apply delay-capable clean/smudge filters (such as Git LFS) What is the simple test for whether this is the case or not? Is this a default-on scenario?
No, LFS is something you would have to explicitly enable, however it is pretty common to do so if you want to store binary blobs in Git.