Linus Torvalds <torva...@linux-foundation.org> writes: > So *if* the new object format uses a git header line like > > "blob <size> <sha1>\0" > > then it would inherently contain that mapping from 256-bit hash to the > SHA1, but it would actually also protect against attacks on the new > hash.
This is easy for blobs as you only need to hash twice. I am not sure if you can do the same for trees, though. For that <sha1> to be useful, the hash needs to be over the tree contents whose references are expressed in <sha1>, which in turn would mean... ... ah, you would read these <sha1> off of the object header in the new world and you do not need to expand the whole thing. OK, I see how it could work. > In fact, in particular for objects with internal format that > differs between the two hashing models (ie trees and commits which to > some degree are higher-value targets), it would make attacks really > quite complicated, I suspect. > > And you wouldn't need those "hash" or "nohash" things at all. The old > SHA1 would simply always be there, and cheap to look up (ie you > wouldn't have to unpack the whole object).
