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

Git security vulnerability announced

github.blog

Post reply on HN
Print view View original

121–130 of 302 posts

Re: Git security vulnerability announced

#121

Post by hsbauauvhabzb »

megous wrote: post #31
hsbauauvhabzb wrote: post #10

This is silly. Fix PS1, I can’t trust all repos I clone. I also want to cross-user access git log/blame etc.

Can't you? What kind of foreign code can be executed that way? Clonning will not copy .git/hooks/ nor .git/config which is the main danger here, I guess. But I'd sure want to hear about other risks. Maybe an env variable to disable hooks execution and .git/config parsing would be nice to have for safer use of git repositories you didn't clone yourself as part of shell prompt customizations.

Git clone doesn’t mean I’m blindly executing the code inside it.

Re: Git security vulnerability announced

#122

Post by saagarjha »

tedunangst wrote: post #79
saagarjha wrote: post #59

I shouldn’t ask too much of an open source project, etc. etc., but this sounds like something Git should fix themselves rather than just outright disabling. “I want to go into a directory and run git log” is kind of a simple thing to want to do and to not be able to do that sucks. It’s easy to pontificate on this forum but having a “safe” git that doesn’t automatically run hooks or whatever seems like the way forward…

Hmmm. git status seems like a simple read only command, but it can run a hook, which will change the result. So a default of no hooks might mean subtly or silently different, depending on who runs command, which can be really annoying kind of breakage to track down. "Why didn't the build start? Why wasn't the change noticed? I can see it." I can imagine wanting to avoid that scenario. Painted themselves into a bit of…

Right, I get the perspective, I’m just saying that there’s a lot of usecases where I know I don’t want this (PS1, git directory in /tmp, SSH into a shared machine) where I just want simple git commands to work, and a “git --safe” or something would be really helpful. I’m not even sure what the alternative would be here for a lot of these cases, besides writing my own “dumb” porcelain…

Re: Git security vulnerability announced

#123

Post by eru »

edgyquant wrote: post #113
hda2 wrote: post #84

Earlier quoted context omitted.

Wait, I thought git hooks aren't pulled from remote. Wouldn't untrusted git hooks mean that git verify-* are useless since you're already running untrusted code?

On my current app we use husky which installs hooks when you do a yarn install

You are in luck, it seems: https://blog.typicode.com/husky-git-hooks-autoinstall/

(Though not completely sure.)

Re: Git security vulnerability announced

#124

Post by saagarjha »

kadoban wrote: post #73
saagarjha wrote: post #59

I shouldn’t ask too much of an open source project, etc. etc., but this sounds like something Git should fix themselves rather than just outright disabling. “I want to go into a directory and run git log” is kind of a simple thing to want to do and to not be able to do that sucks. It’s easy to pontificate on this forum but having a “safe” git that doesn’t automatically run hooks or whatever seems like the way forward…

Git is a very conservative project, that they did it like this suggests that they had very good reason to. Nobody is perfect, but the git team has earned a lot of trust over the years. I plan to read up on it more and wait for the CVE to be clearly explained before trying to backseat it, myself. No criticism intended.

I respect the git authors as well, and I feel like I understand their perspective. I’m just curious why they chose this balance instead.

Re: Git security vulnerability announced

#125

Post by saagarjha »

db48x wrote: post #70
saagarjha wrote: post #59

I shouldn’t ask too much of an open source project, etc. etc., but this sounds like something Git should fix themselves rather than just outright disabling. “I want to go into a directory and run git log” is kind of a simple thing to want to do and to not be able to do that sucks. It’s easy to pontificate on this forum but having a “safe” git that doesn’t automatically run hooks or whatever seems like the way forward…

On the one hand I agree with you; on the other hand that would entail enumerating all possible unsafe configurations. In general when designing a security measure you never want to try to enumerate everything that could be unsafe, because there is always an attacker who is more clever than you are who will think of something you left off the list.

Yes, but I feel like the other thing you need to keep in mind here is that this is going to be a massive pain for a lot of people, and they might end up doing things that are substantially worse for security, like refusing to update their git.

Re: Git security vulnerability announced

#126

Post by krick »

gruez wrote: post #92
krick wrote: post #80

This is bullshit. I mean, ok, you are concerned about somebody using git-enabled PS1. Guess what, not everyone is using git-enabled PS1. Unbelievable, right? I would even mock the fact that you are trying to protect users from the behavior they pretty much explicitly allowed, but this is pointless. Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying…

>Guess what, not everyone is using git-enabled PS1 not everyone is running on a multi-user system either (realistically speaking, most personal computers are single user). That doesn't mean microsoft/apple/linux doesn't care about escalation of privilege exploits. >Truth is, developers are doing something that can fuck up their system daily. Let's forget about wget | bash and copying completely untrusted git reposito…

I am tempted to say that no matter who you are, I am pretty much positive you are doing dumb shit daily, and pretending you are not is laughable, but that would be off the point: I pre-emptively answered your 2 first points in the original comment, so I'm ignoring them. The only part that requires an answer is this:

> but then what if you need hooks?

Now that's just genius! So, making it possible to disable the functionality that specifically allows for the execution of arbitrary code (which is questionable on its own to say the least — it's pretty much the definition of aforementioned "dumb stuff") is bad, because having to enable it back is "inconvenient", and disabling the whole multi-purpose tool that git is (which has hundreds of user scenarios that don't require allowing to execute arbitrary commands) is good? This is a rhetorical question of course, just think about what you are saying. Worth nothing that making enabling it back inconvenient is a strawman of yours: this is precisely my point that even what they did would be ok, if I was allowed to simply disable their "fix". And it's exactly the problem, that there's no convenient option to do so.

Re: Git security vulnerability announced

#127

Post by pvg »

Dylan16807 wrote: post #115
pvg wrote: post #108

Earlier quoted context omitted.

The original link barely made any sense and many of those comments were comments without the useful context. The root cause here is the iffy submission, not the outdated comments or the change to a more meaningful link.

The original title was "Git 2.30.3 will not operate in non-owned directories" which makes perfect sense to me, and the link provides a good explanation of the security problem. What barely makes any sense about it?

It's a made-up title linking to some random commit. The new link tells you it's a fix for a vulnerability, the details, its CVE, affected platforms and use cases, etc, etc. The other thing doesn't.

Re: Git security vulnerability announced

#128

Post by [deleted] »

hda2 wrote: post #75

Was this change discussed publicly prior to merge? I think this is a big mistake. Build environments use separate users for security purposes. It's insane to decrease security for everyone by requiring a single user to do everything because some of your users want to have fancy terminal prompts. At the very least, let users configure this at a per-user level.

[deleted]

Re: Git security vulnerability announced

#129

Post by Dylan16807 »

pvg wrote: post #127
Dylan16807 wrote: post #115

Earlier quoted context omitted.

The original title was "Git 2.30.3 will not operate in non-owned directories" which makes perfect sense to me, and the link provides a good explanation of the security problem. What barely makes any sense about it?

It's a made-up title linking to some random commit. The new link tells you it's a fix for a vulnerability, the details, its CVE, affected platforms and use cases, etc, etc. The other thing doesn't.

The title was "made up", I'll give you that, but it's a pretty good paraphrase of the commit title to add context.

The old link also tells you it's a fix for a vulnerability, and also explains how it affects all platforms, and also talks about the use cases etc etc.

The only thing it doesn't have is a CVE number, which I don't think is all that important.

Post reply on HN