Re: [RCF] Secure git against involuntary arb. code execution without feature loss

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 8, 2025, 21:35 UTC
Message-ID: <aObZPJ3JK-YVI-g7@fruit.crustytoothpaste.net>
In-Reply-To: <72F10412-8B0F-4F66-8674-FE194D016DF9@lohmann.sh>

On 2025-10-08 at 21:02:03, Michael Lohmann wrote:

> Hello everyone,

Hi,

Show 27 quoted lines

> Hooks, as well as certain config (e.g. `core.pager`) can do automatic
> code execution for you. In general, this is a great feature and should
> be kept without the user noticing any changes.
> 
> BUT if you download a random folder which to you unknowingly is a repo
> and either you or e.g. your command line prompt automatically executes a
> simple `git status`, it feels bad if this results in arbitrary code
> execution (ACE), e.g.:
> 
>  https://www.sonarsource.com/blog/securing-developer-tools-git-integrations/
> 
> and
> 
>  https://github.com/justinsteven/advisories/blob/main/2022_git_buried_bare_repos_and_fsmonitor_various_abuses.md
> 
> Apart from one core maintainer, all git user I talked to were surprised
> and shocked by how simple an exploit like this was.
> 
> * Proposed solution (keeping all existing features):
> - On first use, git generates a secret "token" (e.g. a random string in
>   ~/.gitsecret)
> - On calling `git init` or `git clone`, the secret is copied into the
>   new .git directory and serves as proof that this clone was created by
>   this user
> - Before executing any user-defined code, check for the local token:
>   - If present, proceed as usual.
>   - Otherwise abort.

This has all of the downsides of our existing per-Unix user approach and is also more complicated. You'll notice that when we changed to the per-Unix user approach, that broke containers, shared repositories, and even the detection of whether a directory _is_ a repository, and this would do the same thing. It would be even worse for containers because if you copied a token into the container from the container user, you'd end up polluting that directory with lots of useless tokens that never get cleaned up.

It is also easy to bypass, since if we share multiple repositories as collaborators, as soon as I can read the secret from one of them, I can then write it into any other location. It would even be sufficient if we were users on the same system (such as is common in universities or some businesses) and I could read the repository. Many websites even accidentally expose their `.git` directories, which would not only expose their repository but also allow attacks against all of the administrator's repositories.

What would be better to see instead is a config option that restricts which external commands (via config options or hooks) can be executed from local config. Then it would be possible to say, "Never honour local config to execute code." With `includeIf`, this can allowlist certain repositories to do that and leave the rest disabled.

Maybe something like this:

[safe]
  config = core.editor
  config = core.fsmonitor
  hook = pre-receive

If you wanted to implement _that_, I'd be all over it.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA