From: Phillip Wood <phillip.wood123@gmail.com>
Date: Mon, 07 Sep 2026 13:37:04 GMT
Subject: Re: [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode
Message-ID: <9fb6317d-ce64-4f53-bce2-81cb2dc12056@gmail.com>
In-Reply-To: <ao4K44RP66mjnpd7@fruit.crustytoothpaste.net>

Hi brian

Thanks for the examples, sorry it has taken so long for me to respond

On 25/08/2026 22:36, brian m. carlson wrote:
> 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.

I'm a bit unclear how upper case hex can defeat that policy but ref 
names dont. If the input is not being checked to ensure it is a hex 
object id wont a ref pointing to a commit we're trying to restrict 
access to also defeat 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.

That makes more sense to me. It also makes me wonder if we should forbid 
refnames where the last component looks like an object id.

Thanks

Phillip