Re: Git and SHA-1 security (again)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Duy,

On Tue, 19 Jul 2016, Duy Nguyen wrote:

> On Tue, Jul 19, 2016 at 7:59 PM, David Lang <david@lang.hm> wrote:
> > On Tue, 19 Jul 2016, Duy Nguyen wrote:
> >
> >> On Tue, Jul 19, 2016 at 7:34 PM, David Lang <david@lang.hm> wrote:
> >>>
> >>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
> >>>
> >>>> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
> >>>> <Johannes.Schindelin@gmx.de> wrote:
> >>>>>>
> >>>>>>
> >>>>>> 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?
> >>>>
> >>>> Any repo would have a cut point when they move to sha256 (or
> >>>> whatever new hash), if we can record this somewhere (e.g. as a tag
> >>>> or a bunch of tags, or some dummy commits to mark the heads of the
> >>>> repo) then we only verify gpg signatures _in_ the repository before
> >>>> this point.
> >>>
> >>> remember that a repo doesn't have a single 'now', each branch has
> >>> it's own head, and you can easily go back to prior points and branch
> >>> off from there.
> >>>
> >>> Since timestamps in repos can't be trusted (different people's
> >>> clocks may not be in sync), how would you define this cutoff point?
> >>
> >> The set of all heads at the time the conversion happens (maybe plus
> >> all the real tags). We can make an octopus merge commit to cover all
> >> the heads, then it can be the reference point.
> >
> > so to make sure I'm understanding this, anything not reachable from
> > that merge must be the new hash, correct? Including forks, merges, etc
> > that happen from earlier points in the history.
> 
> Yes everything except that merge and everything reachable from it, the
> whole old clone, basically.

But that strategy *still* ignores the distributed nature of Git. Just
because *you* make that merge at a certain point does not necessarily mean
that I make it at that point, too.

Any approach that tries to have one single point of conversion will most
likely fall short of a solution.

To be honest, I am less concerned about the GPG-signed commits (after all,
after switching to a more secure hash algorithm, a maintainer could
cross-sign all signed commits, or only the branch tips or tags, as new
tags, to reinstitute trust).

I am much more concerned about references to commits, both inside and
outside the repository. That is, if I read anywhere on the internet about
Git having added support for `git add --chmod=+x <file>` in 4e55ed3 (add:
add --chmod=+x / --chmod=-x options, 2016-05-31), I want to find that
commit by that reference.

And I am of course concerned what should happen if a user wants to fetch
from, or push to, a SHA-1-hashed remote repository into, or from, a
SHA-256-hashed local one.

Ciao,
Dscho