131–140 of 228 posts
The 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.
> 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?
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.
Earlier quoted context omitted.
Yes, but no sensible people use case-insensitivity on Linux, and the amount of other people that do in a relevant context can probably be measured with four digits.
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.
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.
That could be any Git repository. Have you seen the mayhem that some of mine cause when you clone them and then type ./configure && make, like you have been socially engineered into doing?
There is a huge difference between “clone a repo” and “clone a repo and run code from it”.
> This vulnerability affects platforms with case-insensitive filesystems with support for symbolic links, when certain clean/smudge filters are configured globally (e.g. Git LFS). Can we get the title changed to "on macOS and Windows?" I was worried for a second, but this is meaningless.
Earlier quoted context omitted.
Why is it meaningless? Lots of people use Git on MacOS and Windows. I'd even be willing to bet that there are more people using Git on MacOS and Windows than Linux.
I would assume that most people developing on macOS have configured case sensitive filesystems. And does Windows do symlinks now? Seems like a weird edge case to me. I guess Apple and Microsoft should push out OS updates to cover it.
I don't think this is true at all. Too many things will break if you turn this on.
Earlier quoted context omitted.
Strange. The guy who fixed the issue works at Microsoft, but uses his gmx email for Github.
I think you just got a glimpse of a vast sea of internal policy and compliance issues.
Earlier quoted context omitted.
Sure, I'm just saying this isn't a big deal and its likely no one was hit.
Just because there is not an active threat doesn’t make it any less of a vulnerability to be exploited.
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.