Re: Git and SHA-1 security (again)

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 18, 2016, 23:03 UTC
Message-ID: <20160718230324.GG6644@vauxhall.crustytoothpaste.net>
In-Reply-To: <xmqq4m7mltbw.fsf@gitster.mtv.corp.google.com>

On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> Continuing this thought process, I do not see a good way to allow us
> to wean ourselves off of the old hash, unless we _break_ the pack
> stream format so that each object in the pack carries not just the
> data but also the hash algorithm to be used to _name_ it, so that
> new objects will never be referred to using the old hash.

I think for this reason, I'm going to propose the following approach when we get there:

* We serialize the hash in the object formats, using multihash or
  something similar.  This means that it is minimally painful if we ever
  need to change in the future[0].
* Each repository carries exactly one hash algorithm, except for
  submodule data.  If we don't do this, then some people will never
  switch because the submodules they depend on haven't.
* If people on the new format need to refer to submodule commits using
  SHA-1, then they have to use a prefix on the hash form; otherwise,
  they can use the raw hash value (without any multihash prefix).
* git fsck verifies one consistent algorithm (excepting submodule
  references).

This preserves the security benefits, avoids future-proofing problems, and minimizes performance impacts due to naming like you mentioned.

[0] We are practically limited to 256-bit hashes because anything longer will wrap on an 80-column terminal when in hex form.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204