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
