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

191–200 of 228 posts

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

#191

Post by bvendor »

kazinator wrote: post #86

That could be any Git repository. Have you seen the mayhem that some of mine cause when you clone them and then type ./configure && make, like you have been socially engineered into doing?

I get that you are not completely serious, but before the cmake/meson/... people jump on this:

If ./configure is checked in as part of the official repository of a moderately well known project, I doubt any committer would be stupid enough to insert a backdoor into ./configure or the Makefiles.

What can happen if an apostate project is not on GitHub: Some (usually several) faithful persons decide to correct the situation and put multiple unofficial mirrors on GitHub, and other faithful people clone from a random one of these.

In that case however, they get what they deserve.

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

#192

Post by emodendroket »

memorysafety wrote: post #179
emodendroket wrote: post #96

Earlier quoted context omitted.

Windows has done symlinks (known as "junctions") since Windows 2000, so I guess it's a more recent feature you might not have learned about.

That's a dishonest statement and misrepresents the actual support. The "junctions" are unusable as "windows symlinks". For one, you can't create any as a normal non-admin user without specific authorization by default.

Only the most sadistic company on earth is going to ask you to do development on a Windows machine without admin privileges.

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

#193

Post by 0x0 »

jtsiskin wrote: post #135
minitech wrote: post #119

Earlier quoted context omitted.

There is a huge difference between “clone a repo” and “clone a repo and run code from it”.

Technically yes, but I can’t think of the last time I cloned a repo without then running code from it...

Any html/js web frontend project that runs in a browser?

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

#194

Post by emodendroket »

caslon wrote: post #133
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.

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.

The benefit seems pretty clear to me. Users do not generally consider uppercase and lowercase versions of the letter completely distinct. The use cases for identical file names with different cases would seem quite limited.

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

#195

Post by [deleted] »

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…

[deleted]

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

#196

Post by selfhoster11 »

jrockway wrote: post #90
mateo411 wrote: post #72

I guess I'll have to stop running $ sudo git clone ...

I don't think that smugly not running as root saves normal users; while malware running as your user can't trash your laptop, they can get your Google cookie and read and send emails as you, spend your money, view your private photos, etc.

Relevant XKCD: https://xkcd.com/1200/

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

#197

Post by jamesog »

jnwatson wrote: post #24
Operyl wrote: post #3

Earlier quoted context omitted.

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

FYI, on MacOS, it is a property of the partition, so you can reformat and have a case-sensitive filesystem. Applications may subtly break if they weren't tested on such a filesystem, but I had used one for several years without too many issues.

Since the introduction of APFS I've taken to creating a new APFS volume formatted as case-sensitive, and put my git repositories there.

This has mostly been useful for working on shared repositories where, say, a Linux user (or other user on a case-sensitive filesystem) pushes two branches, say `feature/foo` and `feature/Foo` which works fine for them, but on a case-insensitive filesystem, git gets very upset.

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

#199

Post by adolph »

branko_d wrote: post #170
anyfoo wrote: post #93

Earlier quoted context omitted.

That's because essentially, "state" and "caching" are the same thing on some level. 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...

I like to look at caching as a form of denormalization - introducing redundancy to improve performance. And whenever we have redundancy, we have to make sure all our copies are synchronized, which can be tricky, especially in a concurrent environment. On the other hand, the whole point of normalization in databases is to avoid redundancy and have "single source of truth". I find the concepts of normalization and deno…

In that light, a cache is a form of partition, so it can be available xor consistent with its source.

https://en.wikipedia.org/wiki/CAP_theorem

Post reply on HN