All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: phillip.wood@dunelm.org.uk
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode
Date: Tue, 25 Aug 2026 21:36:36 +0000	[thread overview]
Message-ID: <ao4K44RP66mjnpd7@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <d6940aa6-9336-481b-8ee5-5e3d9f3d3a50@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

On 2026-08-25 at 09:04:36, Phillip Wood wrote:
> Hi brian
> 
> On 30/07/2026 00:32, brian m. carlson wrote:
> > Git has historically allowed either lowercase or uppercase hex for
> > object IDs, but it has always emitted only lowercase.  This has caused
> > people to expect only lowercase and not handle uppercase.
> > 
> > As an example, Git's own example hooks look for "[0-9a-f]" in several
> > places, but there are many other Git-adjacent pieces of software,
> > including Gitolite, which make the assumption that object IDs are always
> > lowercase.  This is not to criticize the authors of these projects, but
> > rather to point out how common this assumption is.  In fact, it's so
> > common that we have only one test in our codebase that fails when we
> > reject uppercase object IDs.
> > 
> > More critically, it leads people to make security-based assumptions that
> > an object ID either does not contain uppercase characters or that an
> > object ID can be expressed uniquely in hex form, neither of which are
> > currently true.  Git itself normally uses binary object IDs, which
> > avoids many of these problems, but most other projects deal primarily in
> > hex object IDs, so they are more affected.
> 
> Can you say a bit more about the security problems please - I'm trying to
> understand why ABCDEF is a security risk when abcdef^0 isn't.

There's two cases I've seen.  The first is that people assume an object
ID is unique in hex form.  So if we have some policy to enforce, say,
that we can't allow certain objects, people will check against the
lowercase version when they may get the uppercase version somewhere
(say, user input or a specially crafted protocol message), which
bypasses the check.

The other case is where we try to distinguish between an object ID and a
ref, branch, or tag.  If our regexp has `[0-9a-f]{40}` or `[0-9a-f]{64}`
and we assume that if it matches it's an object ID and if it's not it's
a ref, that's not correct here.  We'd need to match the uppercase
version as well, but experience shows that people overwhelmingly do not
do that.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

  reply	other threads:[~2026-08-25 21:36 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 23:32 [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 1/6] hex: add functionality for lowercase-only hex brian m. carlson
2026-07-31  7:38   ` Junio C Hamano
2026-08-25 15:39   ` Junio C Hamano
2026-08-25 21:44     ` brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 2/6] hex: allow specifying hex type with hex2chr brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 3/6] hex: make hex_to_bytes accept kind of hex to use brian m. carlson
2026-07-31  7:38   ` Junio C Hamano
2026-08-01 14:35     ` Jeff King
2026-07-29 23:32 ` [RFC PATCH 4/6] hex: label usages of hex parsing for object IDs brian m. carlson
2026-07-31  3:24   ` Junio C Hamano
2026-08-25 16:11   ` Junio C Hamano
2026-07-29 23:32 ` [RFC PATCH 5/6] object-name: use hexval brian m. carlson
2026-08-25 16:19   ` Junio C Hamano
2026-08-25 19:44   ` Elijah Newren
2026-08-25 21:41     ` brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode brian m. carlson
2026-07-31  7:48   ` Junio C Hamano
2026-07-31 12:33     ` Junio C Hamano
2026-08-02 22:09     ` brian m. carlson
2026-08-04 19:32       ` Junio C Hamano
2026-08-04 21:46         ` brian m. carlson
2026-08-05  3:09       ` Michael Montalbo
2026-08-25  9:04   ` Phillip Wood
2026-08-25 21:36     ` brian m. carlson [this message]
2026-08-25 16:36   ` Junio C Hamano
2026-08-25 19:44   ` Elijah Newren
2026-07-30  8:21 ` [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only Junio C Hamano
2026-07-30 21:18   ` brian m. carlson
2026-08-01 14:45     ` Jeff King
2026-08-01 18:22       ` Junio C Hamano
2026-08-02 21:55       ` brian m. carlson

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=ao4K44RP66mjnpd7@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    /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.