On Thu, Jan 25, 2018 at 10:40 AM, Santosh Kondapuram
<SKondapuram_at_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
Received on 2018-01-25 22:27:31 CET