On Sat, Mar 9, 2024 at 3:27 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. nit: 'to', not 'too' > > 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 nit: '$name', not '$hame' > 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@xxxxxxxxxx> > Helped-by: Kyle Meyer <kyle@xxxxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > setup.c | 28 +++++++++++++++++++++++++++- > t/t0035-safe-bare-repository.sh | 26 ++++++++++++++++++++++---- > 2 files changed, 49 insertions(+), 5 deletions(-) Looks good, thanks!
