The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
> (Surprise, the root cause is a cache) Couldn’t it just as well be attributed to improper file path normalization? If we had only lower case ASCII file systems it would not have caused a problem.
Git: Malicious repositories can execute remote code while cloning
151–160 of 228 posts
Re: Git: Malicious repositories can execute remote code while cloning
#152Earlier quoted context omitted.
Here goes the obligatory > There are only two hard things in Computer Science...
I can never remember what they are, though. To avoid this problem, I think I wrote them down on a post-it, but I had too many post-its on my desk so I got rid of them all, and now I can't remember.
Re: Git: Malicious repositories can execute remote code while cloning
#153Earlier quoted context omitted.
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.
The fact that Linux is case-sensitive is the egregious crime. It's a nasty holdover from circa-1970 Unix when case-folding was an expensive operation.
Why would you introduce complexity into the filesystem to try to normalize file names when you can simply, not? I mean, have you _seen_ the mess that is Unicode normalization? Hundreds of different glyphs or whatever that are all considered equivalent, but are actually composed of different bytes. The filesystem should try to make sense of all that, and consider them equivalent paths?
Even if you say "well, just capitalization, not Unicode normalization," there's the whole German letter ẞ => ss (or is it ß?) and similar friends like the Turkish dotted I that have popped up as articles on HN. Absolutely glad Linux filesystems by and large do not attempt to take that on, and treat paths as a bucket of bytes instead.
All for what benefit - so you can type File.txt in the terminal and have the OS find file.txt? That is much more appropriate for the Application layer to resolve, rather than the filesystem.
Bugs like this come from over-engineering. Filesystems should be simple, and follow the principle of least surprise.
Re: Git: Malicious repositories can execute remote code while cloning
#154The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
I am really fascinated by the responses to this comment. So many people exclaiming how many issues are caused by caches. In ten years as a fulltime programmer the only cache issues I've seen are cache misses. It probably has to do with one's field. I'm a game developer mainly dealing with graphics programming.
Re: Git: Malicious repositories can execute remote code while cloning
#155Earlier quoted context omitted.
I can never remember what they are, though. To avoid this problem, I think I wrote them down on a post-it, but I had too many post-its on my desk so I got rid of them all, and now I can't remember.
The two most difficult ones are naming things, cache invalidation, and off-by-one errors. HTH. ;)
Re: Git: Malicious repositories can execute remote code while cloning
#156The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
Strange. The guy who fixed the issue works at Microsoft, but uses his gmx email for Github.
Re: Git: Malicious repositories can execute remote code while cloning
#157Re: Git: Malicious repositories can execute remote code while cloning
#158Earlier quoted context omitted.
May I ask why? 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.
Because case insensitivity causes ambiguity and complexity for no meaningful benefit, and more often than not causes problems like in the post. This isn't a "Linux" thing for me; every UNIX and POSIX system that has been well-designed with the exception of Snow Leopard has had case sensitivity.
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.
Re: Git: Malicious repositories can execute remote code while cloning
#159Earlier quoted context omitted.
I am really fascinated by the responses to this comment. So many people exclaiming how many issues are caused by caches. In ten years as a fulltime programmer the only cache issues I've seen are cache misses. It probably has to do with one's field. I'm a game developer mainly dealing with graphics programming.
A lot of threading issues are also cache related. Forget to properly mark access to shared variables and suddenly every thread /CPU core ends up with its own locally cached version of it.
Along the same lines a lot of GPU programming tutorials warn of inconsistencies between threads and it has never been a problem since I just assume I cannot rely on consistency or order of execution, seeing each thread as separate and independent.