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

Hello everyone,

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.

* Benefit:
- Protects users from ACE when interacting with untrusted repositories.
- Editors would no longer need to prompt the user for "Do you trust this
  repository?" in most cases, because git could prove the clone is user
  generated.
- For new clones, the user wouldn't even notice a change.

* Drawbacks:
- Existing clones would need manual approval once (e.g., via a new
  `git allow` command).

* Migration strategy to ease adoption (risks to be weight up):
- A future minor release of `git` could already silently add the
  token to all clones it is executed in.
- Even if the repo was malicious, ACE has already occured,
- Since the ACE would have already occured, chances are, other forms of
  persistence had been taken
- By the time git 3.0 introduced the breaking change, most active clones
  would be migrated, so users would only manually need to act, if they
  have very infrequently used clones.

* Prototype:
On my machine `git` resolves to a 150 line bash wrapper script with a
rough implementation this proposal:

 https://git.lohmann.sh/michael/nixos-config/src/branch/main/modules/git.sh

With that, `git` is no longer vulnerable against these kinds of attacks.
I also added some more background information/POC in a blog post:

 https://www.lohmann.sh/en/nuggits/002-dangerous-git/

Yes, I know even despite the "silent migration" this would be probably
lead to some pain for some people on the initial adoption of git v3, but
it would make it much safer for everyone to use and in the long run,
nobody would notice. What are your thoughts of weighing long-term risks
with the short-term pain of adopting something like this? Any other
ideas on how to solve this even better?
Feedback welcome!

Michael Lohmann