"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
> Then we'd probably be better off just walking up the entire hierarchy
> and excluding worktrees from embedded bare repositories, or otherwise
> restricting the config we read. That will probably mean we'll need to
> walk the entire directory hierarchy to see if it's embedded (or at least
> to the root of the device) in such a case, but that should be relatively
> uncommon.
I find this direction to notice iffy "user data" and disable it
quite reasonable. A configuration file can define alias, and it
would be yet another attack vector to overload common ones users
likely use ("git co", "git st", ...). There may also be a hooks/
directory.
I wonder if it is an acceptable defence to deliberately "corrupt"
such user data when we notice that they smell fishy, perhaps by
renaming "config" and "hooks", when they are found next to "HEAD"
and "objects" and "refs", to "config.disabled" and "hooks.disabled"?
I am just thinking aloud without assessing if it is sensible or
feasible at ths point.
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.
