Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Jeff King <>
Cc: Patrick Steinhardt <>
Subject: [PATCH 0/8] tightening ref handling outside of refs/
Date: Mon, 29 Apr 2024 04:15:12 -0400	[thread overview]
Message-ID: <> (raw)

This is picking up the discussion from:

The basic issue is that we don't really enforce pseudoref syntax for
names outside of "refs/", so you update random files in .git like:

  git update-ref objects/info/commit-graphs/commit-graph-chain HEAD

This is mitigated a bit by:

  1. You can't usually _overwrite_ files unless they look vaguely
     sha1-ish (in this case the chain file contains hashes of graph
     files, which is enough). So high-ticket items like "config" should
     be immune.

  2. Receive-pack is a bit more careful here, and refuses anything
     outside of "refs/". So you can't get up to any mischief via "git

But I still find it a bit scary/weird in general. And as noted in that
thread, there's some attempt to enforce this that is done
inconsistently. So you can update and read such refs, but are forbidden
to delete them.

Of course all of this becomes a non-issue with reftables, where those
names are not used in the filesystem at all. But even there I think we'd
probably want to consistently enforce the syntax rules (both between
delete/update/read, but also consistency with the files backend).

This series teaches check_refname_format() to enforce these rules (when
instructed; see patch 6 for a discussion of all sorts of complications).

These changes are not backwards-compatible! But that is kind of the
point. This is stuff that was never supposed to work. My concern would
just be that somehow somebody is relying on it. Pay attention
specifically to patches 4, 7, and 8, which are where the behavior
changes are.

  [1/8]: t0600: don't create ref outside of refs/
  [2/8]: t5619: use fully qualified refname for branch
  [3/8]: refs: move is_pseudoref_syntax() definition earlier
  [4/8]: refs: disallow dash in pseudoref syntax
  [5/8]: refs: use is_pseudoref_syntax() in refname_is_safe()
  [6/8]: check_refname_format(): add FULLY_QUALIFIED flag
  [7/8]: refs: check refnames as fully qualified when writing
  [8/8]: refs: check refnames as fully qualified when resolving

 refs.c                                     | 59 ++++++++++++----------
 refs.h                                     |  1 +
 t/                |  2 +-
 t/                    | 20 ++++++++
 t/ |  4 +-
 5 files changed, 57 insertions(+), 29 deletions(-)


             reply	other threads:[~2024-04-29  8:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  8:15 Jeff King [this message]
2024-04-29  8:16 ` [PATCH 1/8] t0600: don't create ref outside of refs/ Jeff King
2024-04-29  8:36 ` [PATCH 0/8] tightening ref handling " Jeff King
2024-04-29  8:42 ` Jeff King
2024-04-29  9:28   ` Patrick Steinhardt
2024-04-30 10:45     ` Jeff King
2024-04-29 15:01 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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 read-only IMAP folder(s) and NNTP newsgroup(s).