Re: Git clone reads safe.directory differently?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 1, 2024, 21:26 UTC
Message-ID: <Zqv9b_B5wKGp331o@tapette.crustytoothpaste.net>
In-Reply-To: <20240801061417.GD621899@coredump.intra.peff.net>

On 2024-08-01 at 06:14:17, Jeff King wrote:

Show 12 quoted lines

> ...this is doing that loosening for upload-pack by default. I'm not sure
> if that is OK or not. My mental model has remained "it is OK to run
> upload-pack on an untrusted repository", but it would make sense to get
> input from folks who looked at this in the past, like Dscho, and/or to
> reassess the threat model from scratch.
> 
> In particular I did not follow all of the potential issues with linked
> local files. Are we good now after other fixes (in which case this patch
> is OK)? Are we good only for non-local clones (so this patch is OK only
> combined with a fix for clone to check ownership for --local mode)? Or
> are there still problems if an attacker controls the repo paths, in
> which case upload-pack should remain conservative?

I think we already have such a patch. In clone, clone_local either has option_shared (in which case we simply refer to the other repository via an alternates file and don't touch it in any way), or it calls copy_or_link_directory, which in turn calls die_upon_dubious_ownership.

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.

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.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA