On Tue, 16 Oct 2012, Jeff King wrote:
On Tue, Oct 16, 2012 at 01:58:06PM -0400, Theodore Ts'o wrote:
I seem to recall that there was at least some discussion at one point
about adding some extra fields to the commit object in a backwards
compatible way by adding it after the trailing NUL. We didn't end up
doing it, but I could see it being a useful thing nonetheless (for
example, we could potentially put the backup SHA-2/SHA-3 pointer there).
I don't see much point in it. If we want to add new backup pointers to
commit objects, it is very easy to do so by adding new header fields.
A much bigger problem is the other places we reference sha1s. The
obvious place is trees, which have no room for backup pointers (either
in headers, or with a NUL trick). But it also means that any time you
have a sha1 that you arrive at in some other way than traversal from a
signature, you are vulnerable to attack. E.g., if I record a sha1 in an
external system, today I can be sure that when I fetch the object for
that sha1, it is valid (or I can check that it is valid by hashing it).
With sha1 collisions, I am vulnerable to attack.
If you have two hashes of the same contents (SHA1 and SHA3) and they both
agree that the file has not been tampered with, you should still be in
good shape just using the SHA1 as a reference.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
