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!"
