From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Git List Mailing <git@vger.kernel.org>
Subject: Re: "git symbolic-ref" doesn't do a very good job
Date: Mon, 01 Aug 2022 11:54:36 -0700 [thread overview]
Message-ID: <xmqqfsifyetv.fsf@gitster.g> (raw)
In-Reply-To: <YugYNzQYWqDCmOqN@coredump.intra.peff.net> (Jeff King's message of "Mon, 1 Aug 2022 14:15:19 -0400")
Jeff King <peff@peff.net> writes:
> Just to keep things moving forward, here it is with a commit message. I
> left you as the author, but if you're OK with it, please tell Junio he
> can forge your sign-off.
>
> -- >8 --
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Subject: [PATCH] symbolic-ref: refuse to set syntactically invalid target
>
> You can feed absolute garbage to symbolic-ref as a target like:
>
> git symbolic-ref HEAD refs/heads/foo..bar
>
> While this doesn't technically break the repo entirely (our "is it a git
> directory" detector looks only for "refs/" at the start), we would never
> resolve such a ref, as the ".." is invalid within a refname.
>
> Let's flag these as invalid at creation time to help the caller realize
> that what they're asking for is bogus.
>
> A few notes:
>
> - We use REFNAME_ALLOW_ONELEVEL here, which lets:
>
> git update-ref refs/heads/foo FETCH_HEAD
>
> continue to work. It's unclear whether anybody wants to do something
> so odd, but it does work now, so this is erring on the conservative
> side. There's a test to make sure we didn't accidentally break this,
> but don't take that test as an endorsement that it's a good idea, or
> something we might not change in the future.
OK. Even if it were HEAD, it does look like a funny thing to do to
point at a shallower ref with a more concrete ref.
> - The test in t4202-log.sh checks how we handle such an invalid ref on
> the reading side, so it has to be updated to touch the HEAD file
> directly.
>
> - We need to keep our HEAD-specific check for "does it start with
> refs/". The ALLOW_ONELEVEL flag means we won't be enforcing that for
> other refs, but HEAD is special here because of the checks in
> validate_headref().
OK.
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> builtin/symbolic-ref.c | 2 ++
> t/t1401-symbolic-ref.sh | 10 ++++++++++
> t/t4202-log.sh | 4 ++--
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/symbolic-ref.c b/builtin/symbolic-ref.c
> index e547a08d6c..1b0f10225f 100644
> --- a/builtin/symbolic-ref.c
> +++ b/builtin/symbolic-ref.c
> @@ -71,6 +71,8 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
> if (!strcmp(argv[0], "HEAD") &&
> !starts_with(argv[1], "refs/"))
> die("Refusing to point HEAD outside of refs/");
> + if (check_refname_format(argv[1], REFNAME_ALLOW_ONELEVEL) < 0)
> + die("Refusing to set '%s' to invalid ref '%s'", argv[0], argv[1]);
Makes sense. Rejecting syntactically invalid thing like double-dot
is something we should have done from day one.
> diff --git a/t/t1401-symbolic-ref.sh b/t/t1401-symbolic-ref.sh
> index 9fb0b90f25..0c204089b8 100755
> --- a/t/t1401-symbolic-ref.sh
> +++ b/t/t1401-symbolic-ref.sh
> @@ -165,4 +165,14 @@ test_expect_success 'symbolic-ref can resolve d/f name (ENOTDIR)' '
> test_cmp expect actual
> '
>
> +test_expect_success 'symbolic-ref refuses invalid target for non-HEAD' '
> + test_must_fail git symbolic-ref refs/heads/invalid foo..bar
> +'
Good.
> +test_expect_success 'symbolic-ref allows top-level target for non-HEAD' '
> + git symbolic-ref refs/heads/top-level FETCH_HEAD &&
> + git update-ref FETCH_HEAD HEAD &&
> + test_cmp_rev top-level HEAD
> +'
> test_done
Strange, but OK.
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 6e66352558..f0aaa1fa02 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -2112,9 +2112,9 @@ test_expect_success REFFILES 'log diagnoses bogus HEAD hash' '
> test_i18ngrep broken stderr
> '
>
> -test_expect_success 'log diagnoses bogus HEAD symref' '
> +test_expect_success REFFILES 'log diagnoses bogus HEAD symref' '
> git init empty &&
> - git --git-dir empty/.git symbolic-ref HEAD refs/heads/invalid.lock &&
> + echo "ref: refs/heads/invalid.lock" > empty/.git/HEAD &&
OK.
> test_must_fail git -C empty log 2>stderr &&
> test_i18ngrep broken stderr &&
> test_must_fail git -C empty log --default totally-bogus 2>stderr &&
next prev parent reply other threads:[~2022-08-01 18:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-30 19:53 "git symbolic-ref" doesn't do a very good job Linus Torvalds
2022-07-30 20:21 ` Linus Torvalds
2022-07-30 20:38 ` Junio C Hamano
2022-07-31 0:18 ` Jeff King
2022-07-31 0:24 ` Jeff King
2022-07-31 0:44 ` Linus Torvalds
2022-08-01 17:43 ` Jeff King
2022-08-01 17:46 ` Jeff King
2022-08-01 18:15 ` Jeff King
2022-08-01 18:54 ` Junio C Hamano [this message]
2022-08-02 0:46 ` Jeff King
2022-08-02 0:57 ` Junio C Hamano
2022-08-01 19:00 ` Linus Torvalds
2022-07-31 19:10 ` Junio C Hamano
2022-08-01 17:36 ` Jeff King
2022-08-01 17:49 ` Linus Torvalds
2022-08-01 18:04 ` Jeff King
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=xmqqfsifyetv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=torvalds@linux-foundation.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