summaryrefslogtreecommitdiff
path: root/diff.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2022-10-22 18:08:59 -0400
committerJunio C Hamano <gitster@pobox.com>2022-10-22 16:39:48 -0700
commit20da61f25f8f61a2b581b60f8820ad6116f88e6f (patch)
treefbf880f19f4b25b125b99edbeff7d229907ead9d /diff.c
parent77a1310e6b3f39f405275faa8c5af02cf5453cb6 (diff)
Git.pm: trust rev-parse to find bare repositories
When initializing a repository object, we run "git rev-parse --git-dir" to let the C version of Git find the correct directory. But curiously, if this fails we don't automatically say "not a git repository". Instead, we do our own pure-perl check to see if we're in a bare repository. This makes little sense, as rev-parse will report both bare and non-bare directories. This logic comes from d5c7721d58 (Git.pm: Add support for subdirectories inside of working copies, 2006-06-24), but I don't see any reason given why we can't just rely on rev-parse. Worse, because we treat any non-error response from rev-parse as a non-bare repository, we'll erroneously set the object's WorkingCopy, even in a bare repository. But it gets worse. Since 8959555cee (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), it's actively wrong (and dangerous). The perl code doesn't implement the same ownership checks. And worse, after "finding" the bare repository, it sets GIT_DIR in the environment, which tells any subsequent Git commands that we've confirmed the directory is OK, and to trust us. I.e., it re-opens the vulnerability plugged by 8959555cee when using Git.pm's repository discovery code. We can fix this by just relying on rev-parse to tell us when we're not in a repository, which fixes the vulnerability. Furthermore, we'll ask its --is-bare-repository function to tell us if we're bare or not, and rely on that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'diff.c')
0 files changed, 0 insertions, 0 deletions