Live data from Hacker News

Git: Malicious repositories can execute remote code while cloning

openwall.com

31–40 of 228 posts

Re: Git: Malicious repositories can execute remote code while cloning

#31
post #22

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)

OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umla... Many fun times trying to copy/move/remove a file and not being able to do so because the input and name stored on fs is actually different bytewise... Seems like linux has the only sane filesystems not trying to mangle paths at all.

If linux doesn't normalize unicode at all, can you have two different files that look like they are named `josé`, depending on if the é is decomposed or not?

Re: Git: Malicious repositories can execute remote code while cloning

#32
post #17

The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )

Difficult problems in programming: (1) cache invalidation (2) off-by-one errors

The classical three problems.

Re: Git: Malicious repositories can execute remote code while cloning

#34
post #11
post #2

> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?

Windows. Its a notable problem with git + Windows that has gotten better over time but still leads to a lot of WTF moments. For many this event is the first time they hear that window's filesystem is case insensitive.

Sometimes it feels like corporate IT creates more security problems than it solves: windows as development machines, solar winds, Fucking McAffee malware on everything.

Re: Git: Malicious repositories can execute remote code while cloning

#36
post #3
post #2

> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?

macOS, to name one. It appears NTFS is also vulnerable according to the posting.

Once spent way longer than I would have liked trying to debug an iOS app issue that couldn’t reproduce and debug in the emulator because iOS devices have a case-sensitive FS, macOS devices typically don’t, and the emulator was subject to the macOS file system’s conventions.

Leaky abstractions all the way down.

Re: Git: Malicious repositories can execute remote code while cloning

#38
post #17

The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )

Difficult problems in programming: (1) cache invalidation (2) off-by-one errors

I thought the two hardest problems were:

1) naming

2) cache invalidation

...

3) off-by-one errors

Re: Git: Malicious repositories can execute remote code while cloning

#39
post #17

The commit that fixes this issue: https://github.com/gitster/git/commit/684dd4c2b414bcf648505e... (Surprise, the root cause is a cache )

Difficult problems in programming: (1) cache invalidation (2) off-by-one errors

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) off-by-one errors

Re: Git: Malicious repositories can execute remote code while cloning

#40
post #22

Earlier quoted context omitted.

OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umla... Many fun times trying to copy/move/remove a file and not being able to do so because the input and name stored on fs is actually different bytewise... Seems like linux has the only sane filesystems not trying to mangle paths at all.

If linux doesn't normalize unicode at all, can you have two different files that look like they are named `josé`, depending on if the é is decomposed or not?

If you use a file system that doesn't normalize lookups, yes you can.
Post reply on HN