Re: bye-bye abbreviated commit IDs

[Simon Josefsson]

Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes:

> [Changing the subject to attract more attention]
>
> Simon Josefsson wrote:
>>   4) using abbreviated short identifiers makes it possible for someone
>>      to create a malicious git commit that matches the hash prefix, and
>>      then it would be unclear which commit the announcement really
>>      referred to.  Not directly comparable, but illustrative on the
>>      problems with truncating hashes is the recent OpenWRT incident
>>      https://openwrt.org/advisory/2024-12-06 and there are now tools to
>>      generate arbitrary short git commit identifers:
>>      https://github.com/not-an-aardvark/lucky-commit
>
> Will the 'git' people deprecate the use of "git rev-parse --short=LENGTH"
> with LENGTH < 10 ?
>
> According to [1], the minimum length is still 4.

Ouch.  I suppose the problem is that there are conceivable use-cases for
truncations, so increase the minimum size seems unrealistic.

What matters is probably changing the logic of the default setting
though, which is currently 'auto'.

There is a reproducability problem with core.abbrev=auto.  The kind of
identifier you get depend on how deep you cloned the git history.  While
the auto setting is clever (you get shortest possible truncation) the
problem is when these identifiers end up in contexts such as version
numbers encoded into tarballs.  I think for these use cases, one ought
to pick a fixed length instead.  Then it doesn't matter how deep clone
you got.

/Simon

> Bruno
>
> [1] https://git-scm.com/docs/git-rev-parse
>
>
>
>
>

signature.asc
Description: PGP signature