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)
OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umla... 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.
Git: Malicious repositories can execute remote code while cloning
31–40 of 228 posts
Re: Git: Malicious repositories can execute remote code while cloning
#32Re: Git: Malicious repositories can execute remote code while cloning
#33Re: Git: Malicious repositories can execute remote code while cloning
#34> 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.
Re: Git: Malicious repositories can execute remote code while cloning
#35> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?
Re: Git: Malicious repositories can execute remote code while cloning
#36> 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.
Leaky abstractions all the way down.
Re: Git: Malicious repositories can execute remote code while cloning
#37Re: Git: Malicious repositories can execute remote code while cloning
#38The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
Difficult problems in programming: (1) cache invalidation (2) off-by-one errors
1) naming
2) cache invalidation
...
3) off-by-one errors
Re: Git: Malicious repositories can execute remote code while cloning
#39The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
Difficult problems in programming: (1) cache invalidation (2) off-by-one errors
The formulation of this joke I tend to see is,
The two hardest problems in programming:
(1) cache invalidation
(2) appropriately naming things
(3) off-by-one errors
Re: Git: Malicious repositories can execute remote code while cloning
#40Earlier quoted context omitted.
OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umla... 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.
If linux doesn't normalize unicode at all, can you have two different files that look like they are named `josé`, depending on if the é is decomposed or not?