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

From: Junio C Hamano <gitster@pobox.com>
To: Glen Choo <chooglen@google.com>
Cc: git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
	justin@justinsteven.com, Taylor Blau <me@ttaylorr.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 15:17:54 -0700	[thread overview]
Message-ID: <xmqqk0bqat4d.fsf@gitster.g> (raw)
In-Reply-To: <kl6lbkx2821q.fsf@chooglen-macbookpro.roam.corp.google.com> (Glen Choo's message of "Fri, 15 Apr 2022 14:33:21 -0700")

Glen Choo <chooglen@google.com> writes:

> FWIW I experimented with turning off bare repo recognition altogether
> and seeing what breaks.

I guess our mails crossed ;-)  I've done a similar one locally and
sent a report out earlier, and I think the part of the function in
question that we disabled is identical.

>     ++ git clone http://127.0.0.1:5550/dumb/repo.git clone-tmpl
>     Cloning into 'clone-tmpl'...
>     fatal: repository 'http://127.0.0.1:5550/dumb/repo.git/' not found
>
> This sounds to me like Git isn't recognizing the static http files as a
> remote Git repo, and if so, --git-dir doesn't sound like it'll save us.

If the http server side we ship _depends_ on the fact that we
historically consider that it is enough to chdir into a directory to
use that directory as a bare repository, it is not all that
surprising that the server side infrastructure needs to do an
equivalent of "export GIT_DIR=." in addition to chdir it already
does into the directory.  There may be other things that the http
responder in the affected test needs to do before it can recognize
that the dumb/repo.git URL refers to a valid bare repository, and
until that happens, the above experiment may not start working.

I am not worried about that kind for breakage all that much, because
it is entirely under _our_ control how an HTTP request received
results in a "git" invocation, how "git clone/fetch ssh://" invokes
the process that runs "git upload-pack" on the other side in the
directory requested, etc.

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.

Thanks.