91–100 of 228 posts
The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )
I guess I'll have to stop running $ sudo git clone ...
Edit: although I am struggling to think of one that clones from an untrusted source.
Earlier quoted context omitted.
Another cachelty
well played. I think that just got added to my standard vocabulary. Caching has caused more errors and bugs that I've had to deal with than I can recall. My favorite was an off by one error where we returned nicely cached info -- just for the previous user who came through our system! :facepalm: That was a bad one.
And the problem with state is that you have to make sure all your state transitions don't cause bugs. What we know as a "cache" is essentially creating new state representing existing state, with all new transitions...
Earlier quoted context omitted.
And use git LFS and cloned a malicious repo? This bug has probably not affected a single user.
Isn't the whole point of announcing security patches so that people can update before they're exploited?
Earlier quoted context omitted.
well played. I think that just got added to my standard vocabulary. Caching has caused more errors and bugs that I've had to deal with than I can recall. My favorite was an off by one error where we returned nicely cached info -- just for the previous user who came through our system! :facepalm: That was a bad one.
Here goes the obligatory > There are only two hard things in Computer Science...
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.
Earlier quoted context omitted.
I guess it shows that I haven't really used either of those in a long time.
macOS has defaulted to be case insensitive largely due to historical and perhaps usability reasons. You can opt to make it case sensitive (and I do, which broke Steam for several years but that also freed my time).
Earlier quoted context omitted.
Per your downvotes - I used to hate jokes on Hacker News and downvote them when I saw them, but I've become more ambivalent. They're a way of amicably sharing culture and experiences with other engineers that transcend any differences in age, gender, race, background, etc. The formulation of this joke I tend to see is, The two hardest problems in programming: (1) cache invalidation (2) appropriately naming things (3)…
The two hardest problems in programming: (1) cache invalidation (3) off-by-one errors (2) appropriately naming things (4) parallel execution [leading to race conditions / ordering bugs]
1) naming
4) concurr2) cache invalidation
ency
3) off-by-one errors
> 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?
As suggested in GitHub's announcement post[1], you can test this with the following:
`git config --show-scope --get-regexp 'filter\..*\.process'` (replace the single quotes by double quotes on Windows Command Prompt)
> Is this a default-on scenario?
On Windows yes, because Git-for-Windows configures Git LFS by default.
[1]: https://github.blog/2021-03-09-git-clone-vulnerability-annou...
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.
And use git LFS and cloned a malicious repo? This bug has probably not affected a single user.