All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Han Young <hanyang.tony@bytedance.com>
Subject: Re: [PATCH 0/1] quote: quote space
Date: Wed, 27 Mar 2024 05:17:42 -0400	[thread overview]
Message-ID: <20240327091742.GA847537@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqfrwlltjn.fsf@gitster.g>

On Tue, Mar 19, 2024 at 03:56:44PM -0700, Junio C Hamano wrote:

> Unfortunately, this loop can terminate prematurely when a crafted
> directory name ended with a SP.  The next pathname component after
> that SP (i.e. the beginning of the possible postimage filename) will
> be a slash, and instead of rejecting that position as the valid
> separation point between pre- and post-image filenames and keep
> looping, we stopped processing right there.
> 
> The fix is simple.  Instead of stopping and giving up, keep going on
> when we see such a condition.

That makes sense, but leaves me with only one question...

> @@ -1292,8 +1292,15 @@ static char *git_header_name(int p_value,
>  				return NULL; /* no postimage name */
>  			second = skip_tree_prefix(p_value, name + len + 1,
>  						  line_len - (len + 1));
> +			/*
> +			 * If we are at the SP at the end of a directory,
> +			 * skip_tree_prefix() may return NULL as that makes
> +			 * it appears as if we have an absolute path.
> +			 * Keep going to find another SP.
> +			 */
>  			if (!second)
> -				return NULL;
> +				continue;
> +

If we saw a NULL from skip_tree_prefix() because it really was an
absolute path, is continuing the right thing? Or put another way: will
we continue to correctly reject such an absolute path, and not
accidentally find a pair of names?

I think it may be OK because true absolute paths imply that the first
entry would start with "/", and we would already have bailed earlier in
the function. So:

  diff --git /foo /bar

will already be rejected at the start of "/foo". And in broken input
like:

  diff --git a/foo /bar

we must assume that the start of "/bar" is a possible name, which is
what your patch is fixing. And in broken mixed input like that, we would
fail to find a valid split point, and correctly return NULL.

I guess these happen in practice with "/dev/null" as the left-hand side.
But there we'd never need the names from this line, since we'd have a
separate "deleted file mode ..." header line.

-Peff

  parent reply	other threads:[~2024-03-27  9:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19  9:52 [PATCH 0/1] quote: quote space Han Young
2024-03-19  9:52 ` [PATCH 1/1] " Han Young
2024-03-19  9:59   ` Kristoffer Haugsbakk
2024-03-19 15:15 ` [PATCH 0/1] " Junio C Hamano
2024-03-19 22:56   ` Junio C Hamano
2024-03-26 21:41     ` Junio C Hamano
2024-03-27  9:17     ` Jeff King [this message]
2024-03-27 14:59       ` Junio C Hamano
2024-03-27 22:11     ` Junio C Hamano
2024-03-28 10:32       ` Jeff King
2024-03-28 11:40         ` Jeff King
2024-03-28 17:05           ` Eric Sunshine
2024-03-28 17:31             ` Junio C Hamano
2024-03-28 21:08               ` [PATCH v2] t4126: make sure a directory with SP at the end is usable Junio C Hamano
2024-03-29  2:18                 ` Junio C Hamano
2024-03-29  5:37                   ` [PATCH] t4126: fix "funny directory name" test on Windows (again) Junio C Hamano
2024-03-29 12:00                     ` Jeff King
2024-03-29 17:21                     ` [PATCH v2] " Junio C Hamano
2024-03-29 18:34                       ` Jeff King
2024-03-29 11:27                   ` [PATCH v2] t4126: make sure a directory with SP at the end is usable Jeff King
2024-03-29 17:01                     ` Junio C Hamano
2024-04-27 14:47                       ` Johannes Schindelin
2024-04-27 17:20                         ` Junio C Hamano
2024-03-28 16:19         ` [PATCH 0/1] quote: quote space Junio C Hamano
2024-03-28 16:30           ` Jeff King
2024-03-28 16:53             ` 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=20240327091742.GA847537@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hanyang.tony@bytedance.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.