Joey Hess writes ("SHA1 collisions found"):
> https://shattered.io/static/shattered.pdf
> https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
>
> IIRC someone has been working on parameterizing git's SHA1 assumptions
> so a repository could eventually use a more secure hash. How far has
> that gotten? There are still many "40" constants in git.git HEAD.
I have been thinking about how to do a transition from SHA1 to another
hash function.
I have concluded that:
* We can should avoid expecting everyone to rewrite all their
history.
* Unfortunately, because the data formats (particularly, the commit
header) are not in practice extensible (because of the way existing
code parses them), it is not useful to try generate new data (new
commits etc.) containing both new hashes and old hashes: old
clients will mishandle the new data.
* Therefore the transition needs to be done by giving every object
two names (old and new hash function). Objects may refer to each
other by either name, but must pick one. The usual shape of
project histories will be a pile of old commits referring to each
other by old names, surmounted by new commits referrring to each
other by new names.
* It is not possible to solve this problem without extending the
object name format. Therefore all software which calls git and
expects to handle object names will need to be updated.
I have been writing a more detailed transition plan. I hope to post
this within a few days.
Ian.