Git client vulnerability announced

Post by lugg » Fri, Dec 19, 2014, 2:18 AM UTC

tlrobinson wrote: post #45

necubi wrote: post #8

Homebrew just updated ( https://github.com/Homebrew/homebrew/pull/35105 ), so Homebrew users should be covered by brew update && brew upgrade git

Ironically, Homebrew uses git to update its package metadata, but presumably you already trust Homebrew to not deliver malicious software (I also don't know if "pull" is vulnerable, or just "clone" and "checkout". Also Homebrew is hosted on Github, which now scans/blocks malicious repos)

    brew update && brew upgrade

Post by ImJasonH » Fri, Dec 19, 2014, 2:28 AM UTC

peff wrote: post #13

tlarkworthy wrote: post #3

> We have also completed an automated scan of all existing content on github.com to look for malicious content that might have been pushed to our site before this vulnerability was discovered did they find any problems? The post doesn't say...

We found 10 repositories which would have been blocked on push with the new restrictions. None of them were found to be malicious.

Post by lugg » Fri, Dec 19, 2014, 2:36 AM UTC

saidajigumi wrote: post #88

cpach wrote: post #77

Earlier quoted context omitted.

Gah. Incidents like this makes me frustrated OS X doesn’t have a solid package manager like APT.

Is package management really at issue here? For Apple supplied software, I think it really boils down to the same thing as other distros/OSes: timeliness of security updates. If Apple isn't able to spin out incremental security updates as quickly as other distributions, I'd say that process issue is the real problem. Honestly, there's also something to be said for two-tier package management, ala OS X with Homebrew.…

Post by thedufer » Fri, Dec 19, 2014, 3:18 AM UTC

userbinator wrote: post #114

I think here is a good argument for not using case-insensitive filesystems - because every single filename comparison gets affected and it can lead to vulnerabilities like this (I wonder what others are out there...) Case-insensitive initially feels like a good idea to some, but I think it's a good example of "trying to do too much" and often in subtle ways that even the user might not fully understand - the definiti…

Post by hoov » Fri, Dec 19, 2014, 3:42 AM UTC

ethomson wrote: post #124

SSLy wrote: post #109

Earlier quoted context omitted.

My quick an dirty (pun intended) experiment concluded that ntfs, while mounted on linux, is case-sensitive. Windows will happily list all files from fs in explorer, whatever case they are, but treat them as one. And this is deep in win32: http://i.imgur.com/sWnCMdq.png (that's cygwin, while on linux, I've put a `small` file in the `test` dir).

You can mount NTFS case sensitive, but you probably don't want case sensitivity if you interop with Windows and, if you don't, why on earth would you use NTFS?