Thread (18 messages) flat view 18 messages, 6 authors, 2016-08-22

Re: Git and SHA-1 security (again)

From: Duy Nguyen <hidden>
Date: 2016-07-20 14:45:00

On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
[off-list ref] wrote:
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help