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

Git: Malicious repositories can execute remote code while cloning

openwall.com

Post reply on HN
Print view View original

201–210 of 228 posts

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

#201

Post by doctor_eval »

minitech wrote: post #150
kazinator wrote: post #143

Earlier quoted context omitted.

In spite of my tongue-in-cheek statement, I get it. It's huge in the context of non-programming uses of Git. If some people are just sharing some text documents with Git, then it's a big deal. This is likely on the rise. E.g. if you look at a site like Github, there is a lot of non-code content in it. Some people stash that content, and other people believe that content to just be harmless files that will never perpe…

It’s a big deal regardless of whether documents or code are being stored. Cloning a repo should not open you up to RCE.

Agreed, I frequently clone repos so I can look at the code in a terminal with grep, with no intention of ever building it.

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

#202

Post by emodendroket »

memorysafety wrote: post #183
Wowfunhappy wrote: post #124

Earlier quoted context omitted.

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.

> mistakes for no reason Don't you think that 65 ≠ 97 is sufficient of a reason?.. I mean, 'A' ≠ 'a', in ASCII, Unicode and even EBCDIC. In computers, those are two distinct characters. This fact won't change no matter how you rationalize your expectations. Thus, pretending that "y.txt" is the same as "Y.txt" is an elaborate lie. Even acknowledging that it's a "white", well-intentioned lie (designed to preserve the m…

Why is this an unacceptable lie but the notion of letters instead of code points is acceptable? Especially one you get into multi-byte characters?

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

#203

Post by mdasen »

toomim wrote: post #78

What's an easy way to fix the default git installation on OSX?

I did a `brew install git` and then deleted /Library/Developer/CommandLineTools/usr/bin/git. You can't delete /usr/bin/git even with sudo (system integrity policy).

After installing git via brew and removing the one in CommandLineTools, /usr/bin/git is showing the latest version.

    me@local % git --version
    git version 2.30.2
I don't know if this is recommended or if it will have negative consequences that i don't know about, but it seemed like the way I could accomplish it. Given that /usr/bin/git is working with the homebrew installed git, I'm hopeful that everything will be good.

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

#204

Post by earthboundkid »

emodendroket wrote: post #97
Jtsummers wrote: post #21

Earlier quoted context omitted.

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

When necessary you can make an auto-expanding volume that's case-sensitive and leave your host FS alone. I have not found that I really want to have differently-cased but otherwise identical filenames in the real world at any point though.

A bug that affects my teams once every few years is a developer will create a file named "A.txt" check it into Git, realize it should be "a.txt" and rename it, and then basically everything will shit the bed and you waste a day figuring out why nothing is working.

A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this same bug enough times to be able to fix it reasonably quickly, but it definitely wastes time for the team.

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

#205

Post by recursive »

memorysafety wrote: post #183
Wowfunhappy wrote: post #124

Earlier quoted context omitted.

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.

> mistakes for no reason Don't you think that 65 ≠ 97 is sufficient of a reason?.. I mean, 'A' ≠ 'a', in ASCII, Unicode and even EBCDIC. In computers, those are two distinct characters. This fact won't change no matter how you rationalize your expectations. Thus, pretending that "y.txt" is the same as "Y.txt" is an elaborate lie. Even acknowledging that it's a "white", well-intentioned lie (designed to preserve the m…

Why does unix show paths as strings? It's a lie.

65 ≠ 'A'.

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

#206

Post by emodendroket »

earthboundkid wrote: post #204
emodendroket wrote: post #97

Earlier quoted context omitted.

When necessary you can make an auto-expanding volume that's case-sensitive and leave your host FS alone. I have not found that I really want to have differently-cased but otherwise identical filenames in the real world at any point though.

A bug that affects my teams once every few years is a developer will create a file named "A.txt" check it into Git, realize it should be "a.txt" and rename it, and then basically everything will shit the bed and you waste a day figuring out why nothing is working. A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this…

Yeah, my current company encourages development in a case-sensitive volume and I assume this is why. But this is more an issue of your development environment working differently than prod than a problem with the notion of case insensitivity per se.

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

#208

Post by jesboat »

earthboundkid wrote: post #204
emodendroket wrote: post #97

Earlier quoted context omitted.

When necessary you can make an auto-expanding volume that's case-sensitive and leave your host FS alone. I have not found that I really want to have differently-cased but otherwise identical filenames in the real world at any point though.

A bug that affects my teams once every few years is a developer will create a file named "A.txt" check it into Git, realize it should be "a.txt" and rename it, and then basically everything will shit the bed and you waste a day figuring out why nothing is working. A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this…

We added a commit hook to block case conflicts.

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

#209

Post by caslon »

goatinaboat wrote: post #158
caslon wrote: post #133

Earlier quoted context omitted.

Because case insensitivity causes ambiguity and complexity for no meaningful benefit, and more often than not causes problems like in the post. This isn't a "Linux" thing for me; every UNIX and POSIX system that has been well-designed with the exception of Snow Leopard has had case sensitivity.

every UNIX and POSIX system that has been well-designed Case sensitivity wasn’t designed; the first Unix couldn’t spare the CPU cycles to do case insensitive matching, which was the norm at the time.

And yet nearly every UNIX system that was well-designed isn't case insensitive. I was pointing out correlation, not causation.

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

#210

Post by enneff »

saagarjha wrote: post #177
skzv wrote: post #173

Earlier quoted context omitted.

Yes, actually, Googlers are encouraged to use their personal Github accounts.

But probably their work email when doing things on company time?

Nope. This is an example of someone working on company time using their personal email.
Post reply on HN