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

Hi,

> 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