On Thu, Jan 25, 2018 at 10:40 AM, Santosh Kondapuram <skondapu...@vitechinc.com> wrote: > Hi Johan, > > I have tried reloading the dump as you suggested with -M 0 option but still > I am running in to the same issue. > Seems like the svn admin could not load the dump due to sha1 collision files. > So the question is how do I identify the sha1 colliding files ? does the > error stack trace say something about it ? > As per the sha1-advisory note if we create a Subversion permission > rule(authz) that block access to the one or both of the files, then tools > like svnsync will not send the colliding content. > So If someone can help me in identifying the colliding files then I would > like to block them and sync my mirror repository. Below is the error I am > hitting. > Any help much appreciated and I am very much new to the subversion. > > https://subversion.apache.org/security/sha1-advisory.txt > > FYI, > svnadmin: E160000: SHA1 of reps '669684 7 1143 195972 > efbdb058ce857b2860cfa245f014f0b9 9db457be74545c184242e57208bf1d56db1f15b2 > 724412-fiyk/_16' and '-1 0 929 195972 efbdb058ce857b2860cfa245f014f0b9 > 9db457be74545c184242e57208bf1d56db1f15b2 724412-fiyk/_16' matches > (9db457be74545c184242e57208bf1d56db1f15b2) but contents differ > svnadmin: E160004: Filesystem is corrupt > svnadmin: E200014: Checksum mismatch while reading representation: > expected: efbdb058ce857b2860cfa245f014f0b9 > actual: 04a53277f405bcbab8a3b1fff9f8c6e0 > > Thanks, > Santosh.
Hi Santosh, Hmmm, I chatted a bit about this on irc with Andreas Stieger. It seems unlikely that you have a real sha-1 collision in your repository. Unless someone committed those on purpose (for instance by committing files from https://shattered.io/). It's also possible that there is another bug in the "sha-1 collision detection code" (one that doesn't get bypassed with the -M0 trick). So, are you sure someone committed such sha-1-colliding files? Also: the revision where it fails, is that the last revision in the dumpstream? Something you could try to get further, or to get more information about what's going on: if you disable rep-sharing SVN should be able to store the sha-1 collision (you won't be able to check out both colliding files in a working copy though). So you could 'svnadmin load' until the revision right before the problematic one, then disable rep-sharing (putting the option enable-rep-sharing = false in db/fsfs.conf), then load the problematic revision. Then you might be able to find out at least the name of the file that's causing the problem. HTH, -- Johan
