I'm not subscribed to this mailing list, so I have no standard way to reply to Philip's email. I don't even know his email address.
> That pattern, all of MD5, SHA1 and size matching, is exactly what > happens if a SHA1 collision is committed using an old version of > Subversion where the rep-cache does not detect collisions. The first > part of the collision would have been committed in r604440 and the > second part in r605556. > > If that is the case, and a SHA1 collision did occur, then: > > svnadmin verify -r604440 path/to/repository > > will succeed while: > > svnadmin verify -r605556 path/to/repository > > will fail with an MD5 checksum error. > > If this is what you see then unfortunately the colliding r605556 content > has been elided and the r605556 revision is corrupt. The revision 605556 is simply the current revision number of the repository at the time of the attempted commit, and is unrelated to the problem. If I attempt the commit now, it's a higher number, but otherwise the same error message. Something I did notice is that the commit I'm trying to do is a reversion to an older version of the same file. The revision of the file throwing the error at 604440 is identical to the file I'm trying to commit, but the file currently in the repository is different. If I commit a dummy version of the file, then commit the version I actually want, the latter commit works. Could the collision be in a "diff" instead of the files themselves? Melissa On Thu, Feb 22, 2018 at 2:45 PM, Matt Simmons <band...@gmail.com> wrote: > 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 <myriac...@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 <band...@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 <myriac...@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!"
