Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: > On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > > > >> >> I think converting is a much better option. Use a single-hash > >> >> storage, and convert everything to that on import/clone/pull. > >> > > >> > That ignores two very important issues that I already had mentioned: > >> > >> That's not true. If you double-check the next part of my message, you I > >> just showed that an automatic two-way mapping could solve these > >> problems! (I even give briefs explanation how to handle referencing and > >> signature verification in those cases.) > >> > >> 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. > > But we can recreate SHA-1 from the same content and verify GPG, right? > I know it's super expensive, but it feels safer to not carry SHA-1 > around when it's not secure anymore (I recall something about > exploiting the weakest link when you have both sha1 and sha256 in the > object content). Rehashing would be done locally and is better > controlled. You could. But how would you determine whether to recreate the commit object from a SHA-1-ified version of the commit buffer? Fall back if the original did not match the signature? That would pose at least these two problems: 1. The point of a signature is trust. If all of a sudden the signature does not match what is supposedly signed, that trust is broken. 2. The point of going to a stronger hash is to increase the trust. If any developer could decide to sign the SHA-1-ified version of any future commit, and Git validating it, it would be even worse than not switching to a new hash: it would leave us open to collision attacks *and* pretend that we prevented such attacks. The more I think about it, the more I am convinced that we have no choice but allow mixed hashes (i.e. both 160-bit SHA-1 and 256-bit new hash, whatever we settle on). Otherwise there would be no reliable and trustworthy upgrade path. But maybe there is a clever strategy I failed to think of? Ciao, Dscho -- 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