Re: Git and SHA-1 security (again)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 21, 2016, 13:19 UTC
Message-ID: <alpine.DEB.2.20.1607211454061.14111@virtualbox>
In-Reply-To: <20160718230324.GG6644@vauxhall.crustytoothpaste.net>

Hi Brian,

On Mon, 18 Jul 2016, brian m. carlson wrote:

Show 13 quoted lines

> On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote:
> > 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].

This adds a lot of redundancy, though, and has an adverse performance impact, no?

Could we not simply require packs to identify the used hash *once*, and use a single hash algorithm per repository?

That would mean that we would have to re-hash packs on-the-fly if, say, talking to a SHA-1 remote from a SHA-256 local repository.

> * 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 we re-hash transparently, we could get away with SHA-256 even for submodules.

Show 11 quoted lines

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

We are not really bound by the 80-column limit when choosing a hash algorithm. We typically refer to a commit by a shorter name, and the 80-column limit applies only to Git's own source code.

Ciao, Dscho