git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	 Joey Hess <id@joeyh.name>,
	 git@vger.kernel.org
Subject: Re: [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends
Date: Tue, 28 May 2024 09:13:46 -0700	[thread overview]
Message-ID: <xmqqr0dl7w3p.fsf@gitster.g> (raw)
In-Reply-To: <8353645a-a684-417a-8b0e-d8cbd7da6b5a@gmail.com> (Phillip Wood's message of "Tue, 28 May 2024 16:02:37 +0100")

Phillip Wood <phillip.wood123@gmail.com> writes:

> What checks do we have in place to prevent git checking out blobs and
> gitlinks to paths under .git/? I'd have thought we should be applying
> the same restrictions to the target of symbolic links as we do to
> those.

We do not even allow ".git" slip into the index (most likely from a
malicious tree object), so a direct "checkout" is not much of an
issue.  Of course you can introduce bugs to that regular mechanism
in the future but that is not the target for 2.45.1's check we are
going to revert.  I think what Dscho worries about in his message is
that we might by mistake write via a symbolic link in the working
tree.  If our procedure to update a checked out blob in the working
tree were open/truncate/write/close an existing file, a checkout
that switches from a version with a symbolic link at path F to a
version with a regular file at path F may end up overwriting the
target of F.  I think the idea was (Dscho can correct me if I am
misleading the log messge of a33fea08 (fsck: warn about symlink
pointing inside a gitdir, 2024-04-10)) that such a bug from
overwriting a file in our repository if we did not allow a symbolic
link F to point into our repository.

  reply	other threads:[~2024-05-28 16:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 19:56 [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends Junio C Hamano
2024-05-21 19:56 ` [PATCH 01/12] send-email: drop FakeTerm hack Junio C Hamano
2024-05-22  8:19   ` Dragan Simic
2024-05-21 19:56 ` [PATCH 02/12] send-email: avoid creating more than one Term::ReadLine object Junio C Hamano
2024-05-22  8:15   ` Dragan Simic
2024-05-21 19:56 ` [PATCH 03/12] ci: drop mention of BREW_INSTALL_PACKAGES variable Junio C Hamano
2024-05-21 19:56 ` [PATCH 04/12] ci: avoid bare "gcc" for osx-gcc job Junio C Hamano
2024-05-21 19:56 ` [PATCH 05/12] ci: stop installing "gcc-13" for osx-gcc Junio C Hamano
2024-05-21 19:56 ` [PATCH 06/12] hook: plug a new memory leak Junio C Hamano
2024-05-21 19:56 ` [PATCH 07/12] init: use the correct path of the templates directory again Junio C Hamano
2024-05-21 19:56 ` [PATCH 08/12] Revert "core.hooksPath: add some protection while cloning" Junio C Hamano
2024-05-21 19:56 ` [PATCH 09/12] tests: verify that `clone -c core.hooksPath=/dev/null` works again Junio C Hamano
2024-05-21 22:57   ` Brooke Kuhlmann
2024-05-21 19:56 ` [PATCH 10/12] clone: drop the protections where hooks aren't run Junio C Hamano
2024-05-21 19:56 ` [PATCH 11/12] Revert "Add a helper function to compare file contents" Junio C Hamano
2024-05-21 19:56 ` [PATCH 12/12] Revert "fetch/clone: detect dubious ownership of local repositories" Junio C Hamano
2024-05-21 20:43   ` Junio C Hamano
2024-05-22  7:27     ` Johannes Schindelin
2024-05-22 17:20       ` Junio C Hamano
2024-05-21 20:45 ` [rPATCH 13/12] Merge branch 'jc/fix-aggressive-protection-2.39' Junio C Hamano
2024-05-23 10:36   ` Reviewing merge commits, was " Johannes Schindelin
2024-05-23 14:41     ` Junio C Hamano
2024-05-21 20:45 ` [rPATCH 14/12] Merge branch 'jc/fix-aggressive-protection-2.40' Junio C Hamano
2024-05-21 21:33   ` Junio C Hamano
2024-05-21 21:14 ` [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends Johannes Schindelin
2024-05-21 21:46   ` Junio C Hamano
2024-05-21 22:13     ` Junio C Hamano
2024-05-22 10:01 ` Joey Hess
2024-05-23  5:49   ` Junio C Hamano
2024-05-23 16:31     ` Joey Hess
2024-05-27 19:51       ` Johannes Schindelin
2024-05-28  2:25         ` Joey Hess
2024-05-28 15:02         ` Phillip Wood
2024-05-28 16:13           ` Junio C Hamano [this message]
2024-05-28 17:47           ` Junio C Hamano
2024-05-23 23:32     ` 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=xmqqr0dl7w3p.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=id@joeyh.name \
    --cc=phillip.wood123@gmail.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 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).