On 24 February 2017 at 16:13, Ian Jackson
<ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.
It would be great to have a rough plan of the transition to a new hash
function.
We are writing a git-based application to store electronic-files for
legislative purposes for EU.
And one of the great questions we face is about git's SHA-1 validity in 5
or 20 years of time from now.
Is it possible to have an assessment of the situation for this transition?
Best regards for your efforts,
Kostis