From: Junio C Hamano <gitster@pobox.com>
To: Michael Lohmann <git@lohmann.sh>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks
Date: Thu, 16 Oct 2025 12:26:21 -0700 [thread overview]
Message-ID: <xmqqv7ke3axu.fsf@gitster.g> (raw)
In-Reply-To: <20251016053322.44495-5-git@lohmann.sh> (Michael Lohmann's message of "Thu, 16 Oct 2025 07:33:21 +0200")
Michael Lohmann <git@lohmann.sh> writes:
> So far, the only option to allow executing git in what it considers to
> be an "unsafe context" is to set this repository as "safe.directory". If
> a user only wants to temporarily execute one command, they would need to
> set the path as safe, execute the command and then remove the path
> again. Forgetting to do the latter would make the user vulnerable if
> this repo was changed afterwards in a malicious way.
If you want to do a one-shot thing, wouldn't ...
$ cd $there
$ GIT_DIR=$(pwd)/.git GIT_WORK_TREE=$(pwd) git ...
... be more or less the standard practice? If you are at the top
level of the working tree (which is why the above example uses
$(pwd)/.git for GIT_DIR), you do not even have to specify
GIT_WORK_TREE and get away with
$ GIT_DIR=.git git ...
In other words, the above argument does not sound like a very strong
justification.
> +--allow-unsafe::
> + Temporarily trust the repository regardless of "safe.directory"
> + configuration or ownership, potentially resulting in arbitrary code
> + execution by hooks or configuration settings.
As the only justification for this new feature to exist that was
explained in the proposed log message was "one shot execution", this
command line option does look justifiable. Even though with the
current system, you do not have to muck with configuration files and
only have to set the GIT_DIR environment variable, passing this
command line option that does not take a value may still be slightly
easier.
> + Equivalent to setting
> + the environment variable `GIT_ALLOW_UNSAFE=1`.
But such an enviornment variable is not justified. Setting an
engironment variable would last until you unset it, and it implies
that it is no longer a single shot use case that this new feature
targets.
> +`GIT_ALLOW_UNSAFE`::
> + This Boolean environment variable can be set to true to skip the
> + safety checks of "safe.directory" configuration and if the user
> + owns the repository before potentially executing arbitrary code
> + from hooks or config.
Please don't add this. It has the same "Forgetting to unset the
environment variable will make the user vulnerable" downside as
temporarily editing your configuration file.
Not convinced why this feature must exist, at least not yet.
next prev parent reply other threads:[~2025-10-16 19:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 9:41 [PATCH 0/5] Allow enforcing safe.directory Michael Lohmann
2025-10-13 9:41 ` [PATCH 1/5] setup: rename `ensure_safe_repository()` for clarity Michael Lohmann
2025-10-13 9:41 ` [PATCH 2/5] setup: rename `die_upon_assumed_unsafe_repo()` to align with check Michael Lohmann
2025-10-14 20:16 ` Junio C Hamano
2025-10-13 9:41 ` [PATCH 3/5] setup: refactor `ensure_safe_repository()` testing priorities Michael Lohmann
2025-10-14 20:32 ` Junio C Hamano
2025-10-13 9:41 ` [PATCH 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks Michael Lohmann
2025-10-13 9:41 ` [PATCH 5/5] setup: allow not marking self owned repos as safe in `ensure_safe_repository()` Michael Lohmann
2025-10-13 11:59 ` D. Ben Knoble
2025-10-13 21:46 ` [PATCH v2 0/5] Apply comments of D. Ben Knoble Michael Lohmann
2025-10-13 21:46 ` [PATCH v2 1/5] setup: rename `ensure_safe_repository()` for clarity Michael Lohmann
2025-10-13 21:46 ` [PATCH v2 2/5] setup: rename `die_upon_assumed_unsafe_repo()` to align with check Michael Lohmann
2025-10-13 21:46 ` [PATCH v2 3/5] setup: refactor `ensure_safe_repository()` testing priorities Michael Lohmann
2025-10-13 21:46 ` [PATCH v2 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks Michael Lohmann
2025-10-13 21:46 ` [PATCH v2 5/5] setup: allow not marking self owned repos as safe in `ensure_safe_repository()` Michael Lohmann
2025-10-16 5:33 ` [PATCH v3 0/5] Allow skipping ownership of repo in safety consideration Michael Lohmann
2025-10-16 5:33 ` [PATCH v3 1/5] setup: rename `ensure_safe_repository()` for clarity Michael Lohmann
2025-10-16 5:33 ` [PATCH v3 2/5] setup: rename `die_upon_unsafe_repo()` to align with check Michael Lohmann
2025-10-16 5:33 ` [PATCH v3 3/5] setup: refactor `ensure_safe_repository()` testing priorities Michael Lohmann
2025-10-16 5:33 ` [PATCH v3 4/5] setup: allow temporary bypass of `ensure_safe_repository()` checks Michael Lohmann
2025-10-16 19:26 ` Junio C Hamano [this message]
2025-10-16 5:33 ` [PATCH v3 5/5] setup: allow not marking self owned repos as safe in `ensure_safe_repository()` Michael Lohmann
2025-10-16 19:33 ` Junio C Hamano
2025-10-16 19:58 ` 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=xmqqv7ke3axu.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@lohmann.sh \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).