[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SHA-1 collision in repository?

From: Myria <myriachan_at_gmail.com>
Date: Thu, 22 Feb 2018 12:30:32 -0800

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

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


Received on 2018-02-22 21:32:52 CET

This is an archived mail posted to the Subversion Users mailing list.