"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.
