Re: [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only

"brian m. carlson" <[email protected]> Thu, 30 Jul 2026 21:18:40 +0000
Newsgroups	org.kernel.vger.git
Message-ID	<[email protected]>
On 2026-07-30 at 08:21:46, Junio C Hamano wrote:
> "brian m. carlson" <[email protected]> writes:
> 
> > As far as I can tell, Git has always emitted hex object IDs in
> > lowercase, but our object ID parser accepts both uppercase and
> > lowercase.  This leads to much software relying on hex object IDs being
> > broken because it doesn't handle uppercase object IDs and this can even
> > lead to security problems when people assume that an object ID has a
> > unique hex form.
> >
> > This series proposes to remove the ability to use uppercase hex in
> > object IDs in Git 3.0.  It is RFC simply because it's not clear if
> > there's the desire to do this, although the series should be fully
> > functional.
> >
> > As further evidence of why we should do this, I'll note that there is
> > exactly one testcase in our testsuite that fails due to this change
> > (fixed in the last patch) and it's not clear that it fails
> > intentionally.  If we decide not to adopt this series, it would probably
> > be prudent to add some additional tests for the uppercase variant of hex
> > object IDs.
> 
> Before going there, we should hear a solid argument why doing this
> might be beneficial longer term.  "Just because we might be able to
> without harming too many users" is probably not good enough, when it
> is not accompanied by "... the (low) risk may be worth taking because
> we will gain such and such benefit".

While I can't speak about the details, I've actually seen multiple
security vulnerabilities show up because people didn't realize that
uppercase hex was a thing in Git object IDs and so filtering or other
sanitizing was ineffective.  That's the real motivation behind this
change.

Also, as patch 6 says, a large amount of Git-adjacent software,
including common implementations such as Gitolite, don't accept them or
don't handle them correctly.  A quick code search for `[0-9a-f]{40}` on
GitHub shows a lot of these tools.  Our own hook examples even use a
similar pattern, and although in that case they are accepting only Git's
output, users see those as examples of how to parse object IDs.

The situation is presently that Git will accept them and this leads to
surprising behaviour, but almost all adjacent software rejects or
mishandles them.  I'm arguing that we should stop accepting hex object
ID formats that cannot be effectively used in the Git ecosystem but
whose presence is effectively only ever the source of misbehaviour and
security vulnerabilities.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
signature.asc (application/pgp-signature, 325 B)