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

From: Jeff King <peff@peff.net>
Date: Oct 9, 2025, 05:24 UTC
Message-ID: <20251009052422.GA1614343@coredump.intra.peff.net>
In-Reply-To: <72F10412-8B0F-4F66-8674-FE194D016DF9@lohmann.sh>

On Wed, Oct 08, 2025 at 11:02:03PM +0200, Michael Lohmann wrote:

Show 8 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.:

We've discussed this a few times over the years. The most recent one I can remember is:

  https://lore.kernel.org/git/ZZr-JLxubCvWe0EU@tapette.crustytoothpaste.net/

I think there are two somewhat orthogonal issues to consider:

  1. How does Git behave differently in an "unsafe" context? In the
     thread above, I propose that it should skip loading config from the
     repo-level $GIT_DIR/config file, and turn off hooks inside the
     repo. Elsewhere, others have proposed finer-grained control (like
     specific config options). IMHO the most important thing here is
     maintainability, and having a scheme where we do not accidentally
     add code that lets an untrusted repository do bad things.

  2. How does the user tell Git which repos are safe or unsafe? You've
     got a scheme here for marking user-created repositories with a
     secret token. I think that could work, but there are other simpler
     methods. E.g., we could pass down information through the
     environment (like we do already for security features like
     GIT_ALLOW_PROTOCOL), or mark a list of safe directories in user- or
     system-level config (like we have already with safe.directories).
     It's perhaps even reasonable to have multiple such mechanisms, as
     they have different tradeoffs in convenience and security.

So in some sense I think talking about this token scheme and Git 3.0 compatibility is putting the cart before the horse. We need (1) first. And then once we have it, I think the simplest thing is not turning it on all the time, but letting commands opt into it through command-line options and environment variables. So you could imagine git-prompt running "git --assume-unsafe" or setting "GIT_ASSUME_UNSAFE=1" in the environment. People who want to be more paranoid can set that variable for their normal commands to opt into greater security (at the cost of convenience).

Then once we have some practical experience with the system, we can consider whether we should flip the default. And in the meantime we can experiment with idea like your token scheme.

-Peff