Hacker News Reader

Comment by saagarjha | Hacker News Reader

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 here, and useful outside of even just a “I want my PS1 to work”.

View on HN

Their solution sounds reasonable. I don't particularly get why this is even a new vulnerability? If someone manages to create a .git at the root, that means the whole filesystem is under version control and appropriate hooks should execute. Why would this be surprising behavior now? In any "multi user system" as the article says, this would need root access and such a user can do many other bad things if their intent is malicious. I feel like I'm missing something obvious?

I can run git init in /tmp.

Then don't run commands in PS1 that blindly execute arbitrary code in that directory.

Honestly, people haven't learned a single thing from Window's autorun days.

I mean, I don't have git status in PS1 anyway, but I woke up today not knowing that git status will run arbitrary commands. The documentation for git-status does not mention this possibility, like git-commit and git-pull do.

> Then don't run commands in PS1 that blindly execute arbitrary code in that directory.

That's like telling people "be secure". Nobody expected that git commands would do that, and also they shouldn't do that.

Not that I think this is a good fix...

This is kind of why I’d want a git command that doesn’t blindly execute arbitrary code from the directory, as I mentioned above.

The intention of someone running `git log` or `git status` isn't to execute arbitrary code, it's to see a log or the changed files. Telling people "just don't run arbitrary untrusted code" is useless advice when the whole problem is that git runs arbitrary untrusted code in situations where most people wouldn't expect it to execute arbitrary code.

At least spend a couple seconds to think about what you're saying and how it relates to the issue at hand. You're being insufferable.

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 a corner I think. There's no such thing as a side effect free read only git repo.

(A better fix would be to allow the command if there's no hooks, which does seem feasible, and only failing if it's actually asked to do something dangerous.)

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…

Not really any sort of realistic alternative by this point but a distinction between 'programmatic git' where everything is explicit and 'interactive git' that has all the implicit config conveniences would have probably made some difference. It doesn't prevent the specific problem but provides space for less draconian fixes.

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.

It’s possible, but I doubt it. 99% of people use a personal computer with just a single user account on it (or they use a phone with no git client, so let’s just think about git users for now). With only one real user account on the machine they are not very likely to encounter this security measure.

Just about anybody that uses docker and mounts a volume is going to have multiple users accessing their files, even if there's only one real user.

Not exactly. Inside the docker container, the files you have bind–mounted will be owned by the same user who runs the git binary. You’ll never even notice the security check.

Today I'm sitting here staring at a 'fatal: unsafe repository warning' in my local workspace in docker and can tell you definitively that I have noticed.

This change broke a lot of workflows.

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.

Reply on news.ycombinator.com