Re: Bare repositories in the working tree are a security risk

From: Taylor Blau <me@ttaylorr.com>
Date: Apr 16, 2022, 00:52 UTC
Message-ID: <YloTQH35r2xVdPm1@nand.local>
In-Reply-To: <xmqqk0bqat4d.fsf@gitster.g>

On Fri, Apr 15, 2022 at 03:17:54PM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> What worries me more is the effect on _other_ people's server
> implementations ("server", because that is one major class of use
> case of bare repositories).  Essentially they need to identify the
> places where they depend on the current behaviour (i.e. going to the
> bare repository is enough to use it) and export GIT_DIR=. when they
> invoke "git" there.  The actual change that is necessary might be
> small, but identifying the places that need such changes may be
> added burden to them.

I'm definitely biased here, but I think that this is probably too big of a burden to place on forge administrators.

Every repository on GitHub (and I suspect GitLab, too) is written as a bare repository on disk, and so having to inject `GIT_DIR=.` into every git invocation, while doable, seems like an unnecessary pain to impose.

I suppose you could hide this behavior behind an opt-in configuration setting, e.g., `core.bareDiscovery` which determines whether or not we will try to discover bare repositories without `GIT_DIR` in the environment. That setting could default to true to avoid breaking existing use-cases.

But I think that's just masking the overall pain that this approach would incur, without providing much protection, so I wouldn't be unhappy to see us pursue a different approach here.

Thanks, Taylor