Re: [PATCH v2] setup: notice more types of implicit bare repositories

>
> Builds directly on top of 45bb9162 (setup: allow cwd=.git w/
> bareRepository=explicit, 2024-01-20).
>
> Instead of saying "primary worktree's $GIT_DIR is OK", "secondary
> worktree's $GIT_DIR is OK", and "submodule's $GIT_DIR is OK"
> separately, let's give them a name to call them collectively,
> "implicit bare repository" (for now, to reuse what an earlier commit
> used, which may not be an optimum name), as these share the same
> security guarantee and convenience benefit.
>
> The code got significantly simpler, and test moderately more
> complex, having to set up submodule tests.
>
> ------- >8 ------------- >8 ------------- >8 -------
> Setting the safe.bareRepository configuration variable to explicit
> stops git from using a bare repository, unless the repository is
> explicitly specified, either by the "--git-dir=<path>" command line
> option, or by exporting $GIT_DIR environment variable.  This may be
> a reasonable measure to safeguard users from accidentally straying
> into a bare repository in unexpected places, but often gets in the
> way of users who need valid accesses too the repository.

>
> Earlier, 45bb9162 (setup: allow cwd=.git w/ bareRepository=explicit,
> 2024-01-20) loosened the rule such that being inside the ".git"
> directory of a non-bare repository does not really count as
> accessing a "bare" repository.  The reason why such a loosening is
> needed is because often hooks and third-party tools run from within
> $GIT_DIR while working with a non-bare repository.
>
> More importantly, the reason why this is safe is because a directory
> whose contents look like that of a "bare" repository cannot be a
> bare repository that came embedded within a checkout of a malicious
> project, as long as its directory name is ".git", because ".git" is
> not a name allowed for a directory in payload.
>
> There are at least two other cases where tools have to work in a
> bare-repository looking directory that is not an embedded bare
> repository, and accesses to them are still not allowed by the recent
> change.
>
>  - A secondary worktree (whose name is $name) has its $GIT_DIR
>    inside "worktrees/$name/" subdirectory of the $GIT_DIR of the
>    primary worktree of the same repository.
>
>  - A submodule worktree (whose name is $hame) has its $GIT_DIR

>    inside "modules/$name/" subdirectory of the $GIT_DIR of its
>    superproject.
>
> As long as the primary worktree or the superproject in these cases
> are not bare, the pathname of these "looks like bare but not really"
> directories will have "/.git/worktrees/" and "/.git/modules/" as a
> substring in its leading part, and we can take advantage of the same
> security guarantee allow git to work from these places.
>
> Extend the earlier "in a directory called '.git' we are OK" logic
> used for the primary worktree to also cover the secondary worktree's
> and non-embedded submodule's $GIT_DIR, by moving the logic to a
> helper function "is_implicit_bare_repo()".  We deliberately exclude
> secondary worktrees and submodules of a bare repository, as these
> are exactly what safe.bareRepository=explicit setting is designed to
> forbid accesses to without an explicit GIT_DIR/--git-dir=<path>
>
> Helped-by: Kyle Lippincott <spectral@google.com>
> Helped-by: Kyle Meyer <kyle@kyleam.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  setup.c                         | 28 +++++++++++++++++++++++++++-
>  t/t0035-safe-bare-repository.sh | 26 ++++++++++++++++++++++----
>  2 files changed, 49 insertions(+), 5 deletions(-)