Hi Johannes, >> My point is not to throw out old hashes and break signatures. My point >> is to convert the data storage, and use mapping to resolve problems >> with those old hashes and signatures. > > If you convert the data storage, then the SHA-1s listed in the commit > objects will have to be rewritten, and then the GPG signature will not > match anymore. > > Call e.g. `git cat-file commit 44cc742a8ca17b9c279be4cc195a93a6ef7a320e` > to see the anatomy of a gpg-signed commit object. > Yes and no. That's the reason you need the two-way lookup table. If you need to verify a commit which was signed as SHA-1, you must use the lookup table in reverse. This way you can reconstruct the original commit structure, which than can be verified. Of course it's work to do so but you only need to develop the new signature verification algorithm. You save much more on the other side where you don't have to rework all the other algorithms to multi-hash. Another interesting point is that multi-hash storage, actively hurts signature security! (Duy just mentoined that while I'm writing.) A signed commit (or tag) is just as secure as the least secure hash it refers (directly or indirectly). Let's imagine that you make a new a commit, and there is on old file in the tree somewhere. That's a weak point: cause it has SHA-1 hash, someone can replace it (and thus change your commits content. I would clearly mark any signature wether it's SHA-1 or SHA2 (or anything else) based, and strictly allow that hash in all the trees and objects while verifying that commit. If it's not the same hash-type as the storage-key, than use the lookup table for conversion before check. (This has some interesting side-effects, but it's all about good implementation). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html