Re: Git clone reads safe.directory differently?

[Junio C Hamano <gitster@pobox.com>]

"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.