Junio C Hamano <gitster@xxxxxxxxx> writes: > I am not sure if "walking the hierarchy up" is an effective enough > defence offhand. Do we consider it too much social engineering to > make the user follow cloning instruction of the malicious project to > prepare a repository, with core.worktree set to elsewhere, and pull > into it? Since walking up from any subdirectory of the directory > the core.worktree points at will never see a directory, with ".git/" > subdirectory that is the malicious project, "git status" run in the > "embedded" place in such a scenario will not notice that it is a > repository lookalike that came from outside. But we can write it > off as an approach needing too much social engineering, that's OK. In other words, an attacker could lead the victim to clone their malicious repository at path $R with core.worktree in its configuration file $R/config pointing at some directory $D that is entirely unrelated to $R. In a subdirectory of $D (i.e. the working tree of that malicious repository) there may be a directory $G with HEAD, refs and config in it. When the victim visits such a directory $G, going up from there to the root of the filesystem would not find any directory with ".git/" subdirectory in it, so your protection may not even notice that $G came from a checkout of $R.
