# Re: \[BUG\] Git 2.39.0+ Git.pm ignores Directory=\> argument for bare repos

- From: Junio C Hamano \<hidden\>
- Date: 2023-07-31 15:44:27 
- List: git
- Page: https://ratatoskr.run/git/2023/07/7973027
- Thread: https://ratatoskr.run/git/2023/07/7973027/t.md

```text
Hank Leininger [ref] writes:

> Recent git versions (2.39.0 through 2.41.0) Git.pm seems to forget its
> Directory argument for bare repos. Initial creation of a
> Git->repository object will succeed, but subsequent $repo->command()
> fails unless the repo is in pwd or is set in the GIT_DIR environment
> argument.

$ git log --oneline v2.38.0..v2.39.0 -- perl/Git.pm
20da61f25f Git.pm: trust rev-parse to find bare repositories
77a1310e6b Git.pm: add semicolon after catch statement

My guess is 20da61f25f is likely the source of the differences, but
it is unclear if that should be called a "bug", as it was done as a
fix for misbehaviour.

commit 20da61f25f8f61a2b581b60f8820ad6116f88e6f
Author: Jeff King [ref]
Date:   Sat Oct 22 18:08:59 2022 -0400

    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.
```