Git security fixes released

LFS could have an option to enable or disable it which is separate from the definitions of the filter commands. Only the filter command lines would need to be set globally.

> At $DAYJOB, we also use repo-local aliases which call scripts in the repo so that we can maintain them sensibly.

That's obviously a gaping security hole if you might run Git commands from a repo someone else has write access to, whether deliberately or accidentally.

Perhaps `git config` could add the ability to configure per-repo settings in the global user configuration files, which you could then import explicitly? Or as with the fix in this article you could globally configure a list of "trusted" repos (or paths containing repos) which are allowed to define commands in the repos' configuration files.

1. The right, but difficult way: Spawn a daemon or daemon-like process (running as yourself, e.g. using systemd's --user functionality, or just by persuading your shell to fork off a coprocess somehow) which knows how to find all of the information that your shell needs to print out its prompt, and then have your shell asynchronously send "I cd'd to a new directory" notifications to this daemon and asynchronously read updated prompt information from the daemon via some pipe/socket nonsense. Then you can get away with running heavy stuff like Git or Mercurial in the daemon, and your shell updates its prompt when the daemon eventually gets back to it.
2. The wrong, but easy way: Take shortcuts such as looking for .git, .hg, etc. by hand, hard-coding paths that you "know" have certain semantics in practice (e.g. "I know that the Git repos always live under /foo/bar/ on this system, so I will match ${PWD} against that prefix and then do [[ -d /foo/bar/$WHATEVER_WE_MATCHED/.git ]] to see whether we're in a Git repo"), etc., and never, ever spawn any more subshells than absolutely necessary (e.g. if a shell function has to return a string, do REPLY="$value" instead of printf "%s\n" "$value", and then you don't need to run it in a command substitution).

Tooling for (1) exists (e.g. zsh-async), but it's slightly more of a PITA to set up compared to just doing (2) everywhere (and also, I don't like running random GitHub code at $WORKPLACE unless it's in the package repository and somebody has vetted it), so you end up with horrible spaghetti code all over your .bashrc/.zshrc/what-have-you. It's a problem, but I wouldn't call it a big problem because ultimately it's just a shell prompt, it doesn't (directly) make $WORKPLACE money or anything like that.

Which was naive. Instructions just said to go to `C:\foo` instead. This may have worked for a while, but then `Documents and Settings` made it easy to run into path length limits (MSVC still has problems with some long filenames) which made projects run back to `C:\foo` and lose their spaces-in-paths test cases.

> but actual development tools like build systems - in the 2020s that don't support spaces in paths is mind-boggling.

IME, the issues actually usually come from autoconf-based (or raw Makefile) packages where quoting those `$(topdir)` and such expansions is pretty lax. In CMake, you're usually OK, but sometimes someone does something that tries to pass paths around without any thought about "might be seen as two words later".