ankostis <ankostis@xxxxxxxxx> writes: > Let's assume that git is retroffited to always support the "default" > SHA-3, but support additionally more hash-funcs. > If in the future SHA-3 also gets defeated, it would be highly unlikely > that the same math would also break e.g. Blake. > So certain high-profile repos might choose for extra security 2 or more hashes. I think you are conflating two unrelated things. * How are these "2 or more hashes" actually used? Are you going to add three "parent " line to a commit with just one parent, each line storing the different hashes? How will such a commit object be named---does it have three names and do you plan to have three copies of .git/refs/heads/master somehow, each of which have SHA-1, SHA-3 and Blake, and let any one hash to identify the object? I suspect you are not going to do so; instead, you would use a very long string that is a concatenation of these three hashes as if it is an output from a single hash function that produces a long result. So I think the most natural way to do the "2 or more for extra security" is to allow us to use a very long hash. It does not help to allow an object to be referred to with any of these 2 or more hashes at the same time. * If employing 2 or more hashes by combining into one may enhance the security, that is wonderful. But we want to discourage people from inventing their own combinations left and right and end up fragmenting the world. If a project that begins with SHA-1 only naming is forked to two (or more) and each fork uses different hashes, merging them back will become harder than necessary unless you support all these hashes forks used. Having said all that, the way to figure out the hash used in the way we spell the object name may not be the best place to discourage people from using random hashes of their choice. But I think we want to avoid doing something that would actively encourage fragmentation.