From: shejialuo <shejialuo@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Karthik Nayak <karthik.188@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
Han Young <hanyang.tony@bytedance.com>,
git@vger.kernel.org, Han Young <hanyoung@protonmail.com>,
Sigma <git@sigma-star.io>
Subject: Re: [PATCH 1/1] files-backend: check symref name before update
Date: Sun, 5 Oct 2025 16:19:21 +0800 [thread overview]
Message-ID: <aOIqCY4vC0Eqiz_M@ArchLinux> (raw)
In-Reply-To: <aN5mOTbGBcr355E6@pks.im>
On Thu, Oct 02, 2025 at 01:47:05PM +0200, Patrick Steinhardt wrote:
> On Thu, Oct 02, 2025 at 02:54:54AM -0700, Karthik Nayak wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > Han Young <hanyang.tony@bytedance.com> writes:
> > >
> > >> From: Han Young <hanyoung@protonmail.com>
> > >>
> > >> In the ref files backend, the symbolic reference name is not checked
> > >> before an update. This could cause reference and lock files to be created
> > >> outside the refs/ directory. Validate the reference before adding it to
> > >> the ref update transaction.
> > >>
> > >> Reported-by: Sigma <git@sigma-star.io>
> > >> Signed-off-by: Han Young <hanyoung@protonmail.com>
> > >> ---
> > >> refs/files-backend.c | 10 ++++++++++
> > >> 1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/refs/files-backend.c b/refs/files-backend.c
> > >> index bc3347d18..d47a8c392 100644
> > >> --- a/refs/files-backend.c
> > >> +++ b/refs/files-backend.c
> > >> @@ -2516,6 +2516,16 @@ static enum ref_transaction_error split_symref_update(struct ref_update *update,
> > >> struct ref_update *new_update;
> > >> unsigned int new_flags;
> > >>
> > >> + /*
> > >> + * Check the referent is valid before adding it to the transaction.
> > >> + */
> > >> + if (!refname_is_safe(referent)) {
> > >
> > > Shouldn't this new condition share the logic with what is done by
> > > fsck? IOW, after doing this
> > >
> > > $ echo ref: refs/../HEAD > .git/HEAD
> > >
> > > "git fsck" or "git refs verify" should barf (if not, we should make
> > > them barf), and this code should use the same logic to notice that
> > > the target of the symbolic ref is bogus.
> > >
> >
> > Good point. I see that 'git fsck' does complain about this:
> >
> > $ git fsck
> > Checking ref database: 100% (1/1), done.
> > Checking object directories: 100% (256/256), done.
> > error: invalid HEAD
> > dangling commit ccd1771e44a18887197d3ee26ca37c2e892b9fb6
> > dangling commit f99d68ea2c378218e2360dee4e24115c404f6a66
> >
> > However 'git refs verify' doesn't...
> >
> > $ git refs verify --verbose
> > Checking references consistency
> > Checking refs/heads/master
> > Checking packed-refs file .git/packed-refs
> >
> > Okay, so this seems like because fsck also parses all references to mark
> > reachability and also parses 'HEAD' via `refs_resolve_ref_unsafe()`
> > which fails.
> >
> > This symref checks and checking root refs is definitely something we
> > should consider adding to 'git refs verify'.
>
> Agreed! Overall, the goal is that all logic to verify references should
> be contained in `git refs verify`, so that git-fsck(1) only needs to
> shell out to that command to perform the full check.
>
> So if this logic isn't yet part of `git refs verify`, we should migrate
> it over.
IIRC, I intentionally didn't implement the code to check the HEAD. HEAD
is so special as its correctness also indicates whether the current
directory is a Git directory. We would check whether the content of HEAD
starts with "refs: ". If not, we would error the user "fatal: not a git
repository".
So, the only check we should do for HEAD is check whether the symref is
valid. When I implemented the code, I think I wrongly forgot to add such
check.
Thanks,
Jialuo
next prev parent reply other threads:[~2025-10-05 8:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 15:08 [PATCH 0/1] files-backend: check symref name before update Han Young
2025-10-01 15:08 ` [PATCH 1/1] " Han Young
2025-10-01 19:22 ` Junio C Hamano
2025-10-02 9:54 ` Karthik Nayak
2025-10-02 11:47 ` Patrick Steinhardt
2025-10-02 13:36 ` Junio C Hamano
2025-10-02 15:30 ` Patrick Steinhardt
2025-10-02 17:34 ` Junio C Hamano
2025-10-05 8:19 ` shejialuo [this message]
2025-10-02 9:34 ` [PATCH 0/1] " Karthik Nayak
2025-10-02 14:45 ` 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=aOIqCY4vC0Eqiz_M@ArchLinux \
--to=shejialuo@gmail.com \
--cc=git@sigma-star.io \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hanyang.tony@bytedance.com \
--cc=hanyoung@protonmail.com \
--cc=karthik.188@gmail.com \
--cc=ps@pks.im \
/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.