Breaking Git with a carriage return and cloning RCE

> no subprocesses

I guess you're okay with breaking all git hooks, including post-checkout, because those are subprocesses as a feature.

You can always run your git operations in a container with seccomp or such if you're not using any of the many features that it breaks

This would also break custom commands. Which if you don't know about it, is a pretty cool feature.

Drop a git-something executable in your path and you can execute it as git something.

Why is this helpful? Just add the executable itself to path and execute it with "something" instead of "git something". Why are we making git an intermediary ? I am kind of stupid and this is genuine.

Because something might make less sense on its own or conflict with another tool.

Because it's thematically a part of a git workflow.

Because if it's part of the repo, you don't depend on the host to take the extra step, which, if you're working from ephemeral instances or places where that step would have to be repeated, is a god send

Because the joke doesn’t land if typing “git gud” doesn’t actually do something.

To your point, I would say that it’s “easy” rather than strictly helpful. There is a plugin I maintain internally that can be invoked by calling “helm <thing>” if I go through the necessary steps to have it installable by the helm plugin command. Under the hood it’s just a small binary that you can put in your $PATH and it’ll work fine, but there are tons of developers and PMs and other people at the company who don’t know what a path variable is, or how to set it, or what a terminal is, or what shell they’re running, or who know that they can do “helm X” and “helm Y”, so why not “helm Z” for my plugin, etc … It would be a hell of a lot easier to just ship the raw executable, but to those people and execs and mangers and stuff, it looks good if I can show it off next to the native stuff.

Whenever I have to help users with it, I notice that nearly everyone uses it with helm and not calling by the binary directly. It just comes down to the fact that presentation and perceived ease of use counts for a lot when people evaluate whether they want to make a tool part of their workflow.

It allows things to be added and removed from the main executable without changing the interface. This means if someone has a good idea everyone starts using, and they implemented it as a subcommand like this, it could eventually be integrated into git without anyone having to migrate. Also all the subcommands are implemented as separate executables like this anyway.

For example in /usr/lib/git-core/ with git 2.25.1 on Ubuntu, "git-rebase" is a symlink to "git". But on an older Centos VM I have access to, in /usr/libexec/git-core/ with git 2.16.5, "git-rebase" is a separate shell script.

Git itself uses this functionality. On my ubuntu system the path is `/usr/lib/git-core/` and in it you see all sorts of bins for "git commands", e.g `git-rm`, `git-mv`, `git-difftool`, etc. A lot of these are just links back to the git binary these days, but many features begin life as a standalone `git-$X` executable, and back in early git days much more functionality was split across executables. (The ones that are now links back to git are largely for scripting purposes, a lot of git "plugins" and various CI type scripts will call `git-mv` rather than trying to get quoting right around calling `git mv` for example.

It also helps make plugins easier to distribute. I don't want to have to type `git-x` sometimes and `git y` others, and if I want my plugin to get adoption, I really really don't want that. So things like git-lfs, git-annex, etc can easily be distributed, documented as a plugin, and generally be considered as "a part of git", rather than a separate command.

This pattern is also not unique to git. Other softwares have followed it, notably cargo.