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

From: Glen Choo <chooglen@google.com>
To: Junio C Hamano <gitster@pobox.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: Thu, 14 Apr 2022 09:41:36 -0700	[thread overview]
Message-ID: <kl6lh76v8vnj.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <xmqqwnfs4kud.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> Glen Choo <chooglen@google.com> writes:
>
>> Martin observed that, viability aside, there's another approach that I
>> haven't discussed:
>>
>>   == 5 Disable bare repo discovery
>>
>>   We could introduce a config value that disables bare repo discovery
>>   altogether. This would only disable _discovery_; a user can still use
>>   the bare repo by specifying the gitdir (e.g. via `--git-dir=.` or
>>   GIT_DIR).
>
> Does it or does it not count as "allowing discovery to do its job"
> if you go to the directory, knowing that the directory is a bare
> one, and expect Git to work in it?
>
> I am guessing that your definition of "discovery" is not even
> consider if the current directory is a repository and always force
> the user to tell us with --git-dir or GIT_DIR.

Yes, I mean that even the current directory will be ignored when
discovery is disabled.

>                                                I am not sure that
> is realistically feasible (I am thinking of cases like "git fetch"
> going to the remote repository on the local disk that is bare to run
> "git upload-pack"), but if the fallout is not too bad, it may be a
> good heuristics.

Good detail - I hadn't considered the impact on our own child processes.
I suspect this might be a huge undertaking. Unless there is significant
interest in this option, I probably won't pursue it further.