Re: Git clone reads safe.directory differently?

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

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

> The other case, where is_local is not set (and thus clone_local is not
> called), calls transport_fetch_refs, which either calls
> fetch_refs_via_pack or fetch_refs_via_bundle, both of which I assume
> actually make a git-upload-pack call.

OK.

> One related topic that is potentially interesting as well is whether
> `git bundle create` also offers the same security guarantees as `git
> upload-pack` in that it can be safely run on an untrusted repository.
> Either way, we may want to document that.

True.  I think "bundle create" in that regard can be viewed as a
thin wrapper around pack-objects and there is no customization
possibilities (smudge/clean filters, hooks, etc.) that malicious
repositories can take advantage of.

But what worries me more is the fact that any such evaluation can
only be about the current state.  A careless change to say
pack-objects [*] that allows innocent looking customzation to take
place _could_ turn out to be triggerable by the repository when
upload-pack is run, and the "innocent looking" customization may be
more generic than necessary and can be used creatively to cause
damage.  "Don't allow any customizations to 'rev-list' because its
internal is shared with 'pack-objects' that in turn is run from
'upload-pack'" would not be an answer.

It is unclear to me how to make sure such an evaluation done once in
the past will stay valid.  That is something we need to come up with
a viable approach and document, too.


[Footnote]

 * ... or rev-list or any pieces of machinery that are recursively
   relied on by a command that ought to be kept safe.