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

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:

quoted

Hi brian

On 30/07/2026 00:32, brian m. carlson wrote:

quoted

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