Re: Git clone reads safe.directory differently?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 30, 2024, 22:49 UTC
Message-ID: <xmqqv80m8pha.fsf@gitster.g>
In-Reply-To: <Zqlo-i8uCb1Yr4Jm@tapette.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I think if we're using --no-local (that is, if we're using upload-pack
> instead of creating symlinks), then we should not complain about the
> repository ownership.  It's supposed to always be safe to clone or fetch
> from an untrusted repository, and we shouldn't complain about that.

The safety is promised by "git fetch" when you fetch from some other machine because the only thing you will be seeing from that untrusted source is a bytestream that is the packfile, plus the tips of their histories---nothing runs as yourself in this exchange other than what you control, i.e. "git fetch", locally defined hooks and filters defined by your configuration.. They cannot affect your configuration file and hooks that may name extra programs that may run as you while fetching or cloning.

When you are using "--no-local" on the same machine, I do not think there is any guarantee that "upload-pack" side is safe. And that is where the safe.directory thing needs to kick in.

Stepping into an untrusted repository and running git operations opens up the user the Git process runs as to attacks by the untrusted repository, i.e. you may invoke hooks on the upload-pack side, defined in the source repository that is controlled by others, and that is where the safe.directory thing kicks in. You need to declare that you trust that source repository.