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

From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Glen Choo <chooglen@google.com>,
	git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
	justin@justinsteven.com, martinvonz@google.com,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: Bare repositories in the working tree are a security risk
Date: Fri, 15 Apr 2022 20:52:16 -0400	[thread overview]
Message-ID: <YloTQH35r2xVdPm1@nand.local> (raw)
In-Reply-To: <xmqqk0bqat4d.fsf@gitster.g>

On Fri, Apr 15, 2022 at 03:17:54PM -0700, Junio C Hamano wrote:
> 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