Andreas Stieger wrote on Fri, Feb 24, 2017 at 16:17:44 +0100:
> "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  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.
> > 
> > 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:
1a) Add a pre-commit hook that will reject new instances:
[as posted elsethread by Andreas]
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
This workaround makes checkouts possible. It does not fix the other
symptoms enumerated elsethread.
Received on 2017-02-24 22:41:13 CET