Re: Git and SHA-1 security (again)

Johannes Schindelin [off-list ref] writes:

Hi Junio,

On Mon, 18 Jul 2016, Junio C Hamano wrote:

quoted

"brian m. carlson" [off-list ref] writes:

quoted

I will say that the pack format will likely require some changes,
because it assumes ...  The reason is that we can't have an
unambiguous parse of the current objects if two hash algorithms are in
use....  So when we look at a new hash, we need to provide an
unambiguous way to know what hash is in use.  The two choices are to
either require all object use the new hash, or to extend the objects
to include the hash.  Until a couple days ago, I had planned to do the
former.  I had not even considered using a multihash approach due to
the complexity.

Objects in Git identify themselves, but once you introduce the second
hash function (as opposed to replacing the hash function to a new one),
you would allow people to call the same object by two names.  That has
interesting implications.

[...]

So essentially you are saying that the multi-hash approach has too many
negative implications, right? At least that is what I understand.

Looks more and more like we do need to convert repositories wholesale, and
keep a two-way mapping for talking to remote repositories.

Would you concur?

Not necessarily.

That was me thinking aloud, listing some issues that I would imagine
to be tricky to solve, without even attempting to be exhaustive,
that I expect to see solved in a good end-result implementation.
For example, "I do not see a nice way to solve X myself without
doing Y" in the message you are responding to does not necessarily
mean there is no good solution to X (just "I do not think of any
offhand"), and it does not mean I think it is terrible that we have
to do Y to solve X.