Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git client vulnerability announced

github.com

Post reply on HN
Print view View original

131–140 of 191 posts

Re: Git client vulnerability announced

#131

Post by im3w1l »

SSLy wrote: post #109
ethomson wrote: post #96

Earlier quoted context omitted.

As for common filesystems (for some reasonable value of "common"): NTFS, HFS+ and SMB will probably be case insensitive. ZFS may be case insensitive. There are others that would be exotic these days, like AFP. And with FUSE, could be anything.

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).

Anyone knows what happens if an NTFS partition has both fiLe and file, when used in windows?

Re: Git client vulnerability announced

#132

Post by tillinghast »

cpach wrote: post #77
tptacek wrote: post #10

Earlier quoted context omitted.

Make sure you're not using Apple Git (/usr/bin/git); I renamed mine.

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

Homebrew (http://brew.sh) is pretty darned solid.

Re: Git client vulnerability announced

#133

Post by im3w1l »

akerl_ wrote: post #74
sillysaurus3 wrote: post #25

Should programs periodically check for critical security fixes, and then refuse to run if the current version is affected? It seems like there are a lot of people who don't really pay attention to social media or other security alert channels, who won't have a clue about the extent of this vulnerability. I'm sure they'd update if they knew "if I clone a malicious repo, I'm toast," but there's no way to inform them ex…

I'm not sure how I feel about programs phoning home like that. I tolerate it with apps, but command line tools ought to be doing their stated function when run.

It can be done in a way that preserves privacy: Package manager regularly asks for compromise information. When programs run, they ask package manager if they are compromised.

Re: Git client vulnerability announced

#134

Post by mitchty »

ethomson wrote: post #96
cbd1984 wrote: post #87

Earlier quoted context omitted.

OK, just so everyone is up to speed: Under what circumstances could a Linux filesystem be case-insensitive? I know of three: FAT (specifically vfat, these days), JFS with Option -O, and CIOPFS (Case Insensitive On Purpose Filesystem): http://superuser.com/questions/290480/case-insensitive-parti... http://linux.die.net/man/8/mkfs.jfs http://manpages.ubuntu.com/manpages/hardy/man8/jfs_mkfs.8.ht... http://www.brain-dump…

As for common filesystems (for some reasonable value of "common"): NTFS, HFS+ and SMB will probably be case insensitive. ZFS may be case insensitive. There are others that would be exotic these days, like AFP. And with FUSE, could be anything.

Re zfs, you have to turn case insensitivity off if you want it. The default is case sensitive.

That is: $ zfs get casesensitivity zroot NAME PROPERTY VALUE SOURCE zroot casesensitivity sensitive -

Is what you want in general. Unless you have some reason not to be, in which case you have to worry about the bug.

Re: Git client vulnerability announced

#135

Post by userbinator »

thedufer wrote: post #127
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…

> Unicode characters that are visually identical This was actually a further bug, reported as part of the same CVE - you could also overwrite .git/config by adding any of a number of zero-width Unicode characters that many filesystems ignore when checking for filename equality (but string comparison doesn't, of course).

http://en.m.wikipedia.org/wiki/Unicode_equivalence

http://en.m.wikipedia.org/wiki/IDN_homograph_attack

What seems really scary about this is that even Unicode has several different ways of comparing strings, and the correct one depends on the exact situation, so the common response of "just use a library" doesn't work; for example, if a user were searching for a filename it might make sense for full-width characters to compare equal to half-width ones, but not if opening a file where you wouldn't want e.g. the full width version of /etc/passwd to be equivalent to the half-width one.

Re: Git client vulnerability announced

#136

Post by shanemhansen »

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…

Linus actually has a great rant about brain-dead filesystems that mangle people's data. It's eerily prescient. http://thread.gmane.org/gmane.comp.version-control.git/70688...

Re: Git client vulnerability announced

#137

Post by gizmo686 »

im3w1l wrote: post #131
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).

Anyone knows what happens if an NTFS partition has both fiLe and file, when used in windows?

I just quickly tested this on Windows 7. It showed both a directory for both spelling, but both of them contained the same content corresponding to one of the two directories.

Re: Git client vulnerability announced

#138

Post by Demiurge »

jazzychad wrote: post #79
unspecified wrote: post #73

Earlier quoted context omitted.

Thanks for this. Might want to move the original /usr/bin/git out of the way, rather than outright deleting it, juuuuust in case you end up needing the original binary.

/usr/bin/git is usually a soft symlink, so the original binary is still there when you rm the synlink. You can see the actual location by doing ls -al /usr/bin/git If it's not in fact a symlink then yes you should probably rename it to preserve it.

Yosemite, mine is not
Post reply on HN