Hi Ian,
On Fri, Feb 24, 2017 at 03:13:37PM +0000, Ian Jackson 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.
Agreed.
> * 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.
My thought here is:
a) re-hash blobs with sha256, hardlink to sha1 objects
b) create new tree objects which are mirrors of each sha1 tree object,
but purely sha256
c) mirror commits, but they are also purely sha256
d) future PGP signed tags would sign both hashes (or include both?)
Which would end up something like:
.git/
\... #usual files
\objects
\ef
\3c39f7522dc55a24f64da9febcfac71e984366
\objects-sha2_256
\72
\604fd2de5f25c89d692b01081af93bcf00d2af34549d8d1bdeb68bc048932
\info
\...
\info-sha2_256
\refs #uses sha256 commit identifiers
Basically, keep the sha256 stuff out of the way for legacy clients, and
new clients will still be able to use it.
There shouldn't be a need to re-sign old signed tags if the underlying
objects are counter-hashed. There might need to be some transition
info, though.
Say a new client does 'git tag -v tags/v3.16' in the kernel tree. I would
expect it to check the sha1 hashes, verify the PGP signed tag, and then
also check the sha256 counter-hashes of the relevant objects.
thx,
Jason.