Re: [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 25, 2026, 21:36 UTC
Message-ID: <ao4K44RP66mjnpd7@fruit.crustytoothpaste.net>
In-Reply-To: <d6940aa6-9336-481b-8ee5-5e3d9f3d3a50@gmail.com>

On 2026-08-25 at 09:04:36, Phillip Wood wrote:

Show 24 quoted lines

> 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