Andreas Stieger wrote on Fri, Feb 24, 2017 at 16:17:44 +0100: > Hi, > > "Stefan Hett" wrote: > > On 2/23/2017 9:02 PM, Øyvind A. Holm wrote: > > > This is the only known SHA-1 collision at the moment, but Google will > > > release the collision code in 90 days, so we can expect this not to last > > > forever. > > Reading up on that in an article on a German magazine [1] clarifies that > > the effort to create that hash still quite large (6500 CPU years + 100 > > GPU years to calculate the collision). So this relativates the impact a bit. > > Certainly I'm not trying to say that the situation on SVN's side > > should/could not be improved, though. > > > > [1] > > https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html > > An occurrence of this issue in a production repository with the published > PDFs: > https://bugs.webkit.org/show_bug.cgi?id=168774#c29
Workaround: 1a) Add a pre-commit hook that will reject new instances: https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh [as posted elsethread by Andreas] OR 1b) Edit fsfs.conf, set "enable-rep-sharing" to "false". svnserve/mod_dav_svn will pick up the change at the next client operation (e.g., at the start of the next 'checkout'). In custom applications written against the C API, the change will take effect at the next svn_fs_open4() call. 2) Use 'svn rm URL' to remove the second of the two colliding files. (If you aren't sure which one is second, remove both.) 4) Delete rep-cache.db. (If you have a sqlite3(1) binary, you can try deleting *just* the relevant table rows — those that refer to the collided files' sha1.) 5) Edit the repository's authz file to deny access to the files at their historical paths: [/trunk/shattered-1.pdf] * = [/trunk/shattered-2.pdf] * = This workaround makes checkouts possible. It does not fix the other symptoms enumerated elsethread.
