Re: Git and SHA-1 security (again)

From: Duy Nguyen <pclouds@gmail.com>
Date: Jul 20, 2016, 14:44 UTC
Message-ID: <CACsJy8A3ZTfRRNuYXYD-nzXm6KXHu8cHU6fzfysJxfW0EggKNA@mail.gmail.com>
In-Reply-To: <alpine.DEB.2.20.1607201428030.14111@virtualbox>

On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 6 quoted lines

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

OK I see the difference in our views now. To me an sha256 repo would see an sha1 repo as a _foreign_ DVCS, pretty much like git sees mercurial now. So a transition from sha1 to sha256 is not that different from cvs -> svn -> a dvcs bubble -> git.

Show 14 quoted lines

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

to follow the above, in my view, interaction with sha1 repos go through some conversion bridges like what we have with hg and svn. I don't know if we are going this route. It's certainly simpler and people already have experiences (from previous migration) to prepare for it.

-- 
Duy