<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 25, 2017 at 8:31 PM, Peter Gutmann <span dir="ltr"><<a href="mailto:pgut001@cs.auckland.ac.nz" target="_blank">pgut001@cs.auckland.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looks like the SHA-1 collision claimed its first casualty:<br>
<br>
    <a href="https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/" rel="noreferrer" target="_blank">https://arstechnica.com/<wbr>security/2017/02/watershed-<wbr>sha1-collision-just-broke-the-<wbr>webkit-repository-others-may-<wbr>follow/</a><br>
<br>
specifically:<br>
<br>
    <a href="https://bugs.webkit.org/show_bug.cgi?id=168774#c27" rel="noreferrer" target="_blank">https://bugs.webkit.org/show_<wbr>bug.cgi?id=168774#c27</a><br>
<br>
    It seems that the git-svn mirror stopped updating at r212950, and the bots<br>
    all are red, the svn client prints an error that looks like:<br>
<br>
    0svn: E200014: Checksum mismatch for [...] shattered-2.pdf'<br>
<br>
(the trail of fail continues after that point in the thread).<br>
<br>
However, this is really just bad programming rather than a crypto attack, that<br>
SVN can completely bork itself when it hits a non-unique ID.  It looks like<br>
SVN uses a NoSQL store called FSFS, rather than an SQL store for which the<br>
first CREATE UNIQUE INDEX would have prevented the problem.<br></blockquote><div><br></div><div>For additional hilarity, look at the mitigation: they just ban the offending hash!</div><div><br></div><div>(OK, in all fairness, this *is* the fastest way to prevent some other clown without adequate computational resources from messing up more svn repos.) </div></div></div></div>