From: Junio C Hamano <gitster@pobox.com>
To: "Kyle Lippincott via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Kyle Lippincott <spectral@google.com>
Subject: Re: [PATCH] setup: allow cwd=.git w/ bareRepository=explicit
Date: Sat, 20 Jan 2024 14:26:03 -0800 [thread overview]
Message-ID: <xmqqh6j7ej5w.fsf@gitster.g> (raw)
In-Reply-To: <pull.1645.git.1705709303098.gitgitgadget@gmail.com> (Kyle Lippincott via GitGitGadget's message of "Sat, 20 Jan 2024 00:08:22 +0000")
"Kyle Lippincott via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Kyle Lippincott <spectral@google.com>
>
> The safe.bareRepository setting can be set to 'explicit' to disallow
> implicit uses of bare repositories, preventing an attack [1] where an
> artificial and malicious bare repository is embedded in another git
> repository. Unfortunately, some tooling uses myrepo/.git/ as the cwd
> when executing commands, and this is blocked when
> safe.bareRepository=explicit. Blocking is unnecessary, as git already
> prevents nested .git directories.
In other words, if the directory $D that is the top level of the
working tree of a non-bare repository, you should be able to chdir
to "$D/.git" and run your git command without explicitly saying that
you are inside $GIT_DIR (e.g. "git --git-dir=$(pwd) cmd")?
It makes very good sense.
I briefly wondered if this would give us a great usability
improvement especially for hook scripts, but they are given GIT_DIR
when called already so that is not a big upside, I guess.
> Teach git to not reject uses of git inside of the .git directory: check
> if cwd is .git (or a subdirectory of it) and allow it even if
> safe.bareRepository=explicit.
> My primary concern with this patch is that I'm unsure if we need to
> worry about case-insensitive filesystems (ex: cwd=my_repo/.GIT instead
> of my_repo/.git, it might not trigger this logic and end up allowed).
You are additionally allowing ".git" so even if somebody has ".GIT"
that won't be allowed by this change, no?
> I'm assuming this isn't a significant concern, for two reasons:
>
> * most filesystems/OSes in use today (by number of users) are at least
> case-preserving, so users/tools will have had to type out .GIT
> instead of getting it from readdir/wherever.
> * this is primarily a "quality of life" change to the feature, and if
> we get it wrong we still fail closed.
Yup.
If we really cared (which I doubt), we could resort to checking with
is_ntfs_dotgit() and is_hfs_dotgit(), but that would work in the
direction of loosening the check even further, which I do not know
is needed.
> - if (get_allowed_bare_repo() == ALLOWED_BARE_REPO_EXPLICIT)
> + if (get_allowed_bare_repo() == ALLOWED_BARE_REPO_EXPLICIT &&
> + !ends_with_path_components(dir->buf, ".git"))
> return GIT_DIR_DISALLOWED_BARE;
Thanks.
next prev parent reply other threads:[~2024-01-20 22:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 0:08 [PATCH] setup: allow cwd=.git w/ bareRepository=explicit Kyle Lippincott via GitGitGadget
2024-01-20 22:26 ` Junio C Hamano [this message]
2024-01-22 20:50 ` Kyle Lippincott
2024-03-06 17:27 ` Junio C Hamano
2024-03-08 21:19 ` [PATCH 0/2] Loosening safe.bareRepository=explicit even further Junio C Hamano
2024-03-08 21:19 ` [PATCH 1/2] setup: detect to be in $GIT_DIR with a new helper Junio C Hamano
2024-03-08 21:19 ` [PATCH 2/2] setup: make bareRepository=explicit work in GIT_DIR of a secondary worktree Junio C Hamano
2024-03-08 22:30 ` Junio C Hamano
2024-03-08 23:10 ` Kyle Lippincott
2024-03-08 23:32 ` Junio C Hamano
2024-03-09 0:12 ` Kyle Lippincott
2024-03-09 1:14 ` Junio C Hamano
2024-03-09 3:20 ` Kyle Meyer
2024-03-09 5:53 ` Junio C Hamano
2024-03-09 23:27 ` [PATCH v2] setup: notice more types of implicit bare repositories Junio C Hamano
2024-03-11 19:23 ` Kyle Lippincott
2024-03-11 21:02 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh6j7ej5w.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=spectral@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.