subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Simmons <band...@gmail.com>
Subject Re: SHA-1 collision in repository?
Date Thu, 22 Feb 2018 22:45:56 GMT
I would get more advice from people here before you invest that time. I'm a
relative amateur and would listen to people with more experience than
myself.

--Matt

On Thu, Feb 22, 2018 at 2:29 PM, Myria <myriachan@gmail.com> wrote:

> That was one document we ran into when searching, yes.
>
> We can do an svnsync, but this will take about a week to run--the
> repository is 43 GB with 600,000 commits.  I guess we'll start it now.
>
> On Thu, Feb 22, 2018 at 2:04 PM, Matt Simmons <bandman@gmail.com> wrote:
> > Hi Melissa,
> >
> > That definitely is interesting.
> >
> > I assume you have read
> > http://blogs.collab.net/subversion/subversion-sha1-
> collision-problem-statement-prevention-remediation-options
> >
> > If you do an svnsync to another location and attempt the commit there,
> does
> > the problem replicate itself?
> >
> > --Matt
> >
> >
> > On Thu, Feb 22, 2018 at 12:30 PM, Myria <myriachan@gmail.com> wrote:
> >>
> >> When we try to commit a very specific version of a very specific
> >> binary file, we get a SHA-1 collision error from the Subversion
> >> repository:
> >>
> >> D:\confidential>svn commit secret.bin -m "Testing broken commit"
> >> Sending        secret.bin
> >> Transmitting file data .svn: E160000: Commit failed (details follow):
> >> svn: E160000: SHA1 of reps '604440 34 134255 136680
> >> c9f4fabc4d093612fece03c339401058
> >> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' and '-1 0
> >> 134255 136680 c9f4fabc4d093612fece03c339401058
> >> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' matches
> >> (db11617ef1454332336e00abc311d44bc698f3b3) but contents differ
> >>
> >>
> >> What can cause this?  This file is a binary pixel shader compiled from
> >> a build process.  It's most certainly not Google's SHA-1 collision PDF
> >> files.  We also scanned the repository to confirm that nobody has
> >> committed Google's collision files.
> >>
> >> Occam's Razor suggests that something is wrong with our repository or
> >> Subversion itself, rather than this being a true SHA-1 collision.  In
> >> that case, what is wrong with our repository?
> >>
> >> If this really is a SHA-1 collision, it would be major cryptography
> >> news that someone randomly ran into a second collision without even
> >> trying.  In that case, is there a method by which we could recover the
> >> two files that supposedly have the same SHA-1?  The collision doesn't
> >> appear to be in the file itself, but in some sort of diff or revision
> >> output?
> >>
> >> Thanks,
> >>
> >> Melissa
> >
> >
> >
> >
> > --
> > "Today, vegetables... Tomorrow, the world!"
>



-- 
"Today, vegetables... Tomorrow, the world!"

Mime
View raw message