Re: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 16, 2012, 20:09 UTC
Message-ID: <7v391erxgc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20121016182751.GA30010@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> 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).

This is a tangent (as I do not have anything particularly worth adding on top of what have already been said around the exact SHA-[123] topic), but we probably would want to start thinking about the tree object format "v2" at some point.

Some random thoughts:

 - It is OK if existing versions of Git barfed when asked to read a
   tree object in the "v2" format.  The repository format version
   may need to be bumped up when writing such an object, and
   transfer protocols need to pay attention to it, to avoid
   transferring history with objects in newer representation to
   repositories with older repository format version.

 - We do not need a new "tree v2" object type.  Existing versions of
   Git will barf upon seeing such an object, but that won't be the
   only way to prevent existing versions of Git from misinterpreting
   a tree object recorded in the "v2" format as if it were in the
   current format (e.g. a non-octal in the mode field of the first
   entry causes tree-walk.c::get_mode() to barf).

 - We do not mind two tree objects that encodes the same tree in the
   current and the enhanced formats to have different object names.
   In fact, we care more about the object names derived purely from
   the content of the object as an uninterpreted bytestream, so it
   is expected that they have different object names.

   This will make the path-limited traversal and diff to open more
   trees unnecessarily at the "version bump" boundary in the
   history, but that is normal (think of a project that used to
   record its text files with CRLF and one day decides to convert
   everything to LF; the trees before and after the conversion will
   record logically the same contents "git show" should give an
   emptyness, but the diff machinery needs to go into contents at
   the flag day boundary).

   As long as we do not let random "extension of the day" into the
   new format willy-nilly, the resulting history will still be
   useful and usable.  From that point of view, no parts of the
   additional information we would record in the updated format that
   is not present in the current format should be optional (iow,
   once you decide to use the "v2" format to record a certain tree,
   you will produce an identical and reproducible representation in
   "v2", regardless of your implementation).

All of the above are issues for Git 3.0 and beyond, though ;-).