On Fri, 2025-08-15 at 07:22 -0400, rsbecker@xxxxxxxxxxxxx wrote: > > > Aside from the above, hiding an existing command would potentially > allow a > man-in-the-middle attack. Imagine changing git clone to be something > else, > like cloning a hostile repository. Hiding existing commands could > result in a > HIGH severity CVE in git - I would consider it as such. Please ensure > that no > fix/enhancement is done to support this request. This I don't understand. I mean I hopefully never get a remote git config file e.g. just by cloning some remote repo[0]. So - if git aliases were to be only applied when called from interactive shells - how exactly could there be a MitM without the attacker having already compromised at least one’s user account? Cheers, Chris. [0] Perhaps a bit off topic (my apologies for that) but I had wanted to ask this for a long time - or maybe I've had even brought it up back then, but there was no outcome): I vaguely remember the CVE that cause the introduction of safe.bareRepository, which AFAICS was CVE-2022-24765. I'm not an expert but even back then I had already some doubts whether this really *fully* fixed the issue (for all niche cases), did it? I mean when I do a plain git clone http://hackerz.com/rogue/repo.git then the resulting repo/.git/config cannot contain any configs from an attacker (e.g. rogue alises). What if repo.git itself contained e.g. a ./x/.git subdir with configs? My understanding was, that with safe.bareRepository = explicit, such subrepo .git would never get cloned, so that would be safe. Right? But what if I untar such rogue repo... or perhaps more likely, stumble over it on some network mount? To many users it may not be obvious, that this is a risk. And I guess it might even be exploitable by just cd-ing into the wrong directory (if e.g. git prompt is used). It's also not really clear to me whether any 3rd party git utils/libs (libgit2, etc. pp.) may fall for such attack? And IMO that is different from downloading some untrusted binary and executing it, as e.g. already a cd could cause troubles. Is that the situation as assumed? Are there any plans about doing something against it? One could e.g. keep a central list of pathname of directories that are actually considered repositories... and things like aliases/etc. would only get executed if they belong to these. A git clone could automatically add the new repo to that list (but e.g. un-taring some repo wouldn't cause it to be used as that). Or, in order to allow moving the repo to another pathname without having to re-register it, any "allowed/trusted" repo could get some magic cookie in it's .git dir, which is signed by some key from the user. Could even allow more than one such cookie, so that multiple users could work on a shared repo. Of course this would only fully protect, if all other interfaces/libs to git would also adhere to that. And of course, one could make it configurable, i.e. safe.ignore- untrusted-repos ... for all those who think the whole thing is annoying and rubbish.
