Revert "core.hooksPath: add some protection while cloning"
commit75631a3cd84887657c634a35d1095f4a0884e48a
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Mon, 20 May 2024 20:22:02 +0000 (20 20:22 +0000)
committerJunio C Hamano <gitster@pobox.com>
Tue, 21 May 2024 19:33:08 +0000 (21 12:33 -0700)
treeabf405d3105dc1f7cda30c6e33bb9d77513f8a6b
parent197a772c48652d94ddb340fc6bcd8ed4440ff233
Revert "core.hooksPath: add some protection while cloning"

This defense-in-depth was intended to protect the clone operation
against future escalations where bugs in `git clone` would allow
attackers to write arbitrary files in the `.git/` directory would allow
for Remote Code Execution attacks via maliciously-placed hooks.

However, it turns out that the `core.hooksPath` protection has
unintentional side effects so severe that they do not justify the
benefit of the protections. For example, it has been reported in
https://lore.kernel.org/git/FAFA34CB-9732-4A0A-87FB-BDB272E6AEE8@alchemists.io/
that the following invocation, which is intended to make `git clone`
safer, is itself broken by that protective measure:

git clone --config core.hooksPath=/dev/null <url>

Since it turns out that the benefit does not justify the cost, let's revert
20f3588efc6 (core.hooksPath: add some protection while cloning,
2024-03-30).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config.c
t/t1800-hook.sh