subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Simmons <>
Subject Re: SHA-1 collision in repository?
Date Thu, 22 Feb 2018 22:04:27 GMT
Hi Melissa,

That definitely is interesting.

I assume you have read

If you do an svnsync to another location and attempt the commit there, does
the problem replicate itself?


On Thu, Feb 22, 2018 at 12:30 PM, Myria <> 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!"

View raw message