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.
Received on 2017-02-24 22:41:13 CET