Stefan Sperling wrote on Wed, May 15, 2019 at 07:44:41 -0400:
> On Wed, May 15, 2019 at 07:20:25AM +0100, Paul Hammant wrote:
> > Article: https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/
> >
> > Subversion makes a SHA1 hash for each resource held. It is certainly
> > available as part of the detail for a file/resource, but I don't know
> > to what extend the PUT logic relies on it.
> >
> > The ZDNet article talks of better algorithms, but perhaps isn't an
> > authority on which one is best. I wonder if a pluggable design would
> > work. Separately a mechanism for the server to reject a Subversion
> > client as too old may be needed.
> >
> > - Paul
>
> I don't see a way to break repositories with SHA1 collisions in current
> versions of SVN.
>
> Duplicate content is being rejected on the server ever since the first
> SHA1 collision was found. And this of course happens regardless of which
> particular content produced a collision, and how easy it is for researchers
> to find this colliding content. Also, storing any two distinct contents with
> the same SHA1 checksum has been explicitly declared out of scope for SVN.
>
> So I see no new consequences for SVN from this development.
> Am I missing something?
There are these two scripts:
tools/hook-scripts/reject-detected-sha1-collisions.sh
tools/hook-scripts/reject-known-sha1-collisions.sh
Collisions created by the new attack will not be recognized by the
second script and might or might not be recognized by the first script.
For future reference, Subversion does not depend on either of these two
scripts for correct operation. The fixes stsp and I referred to are
implemented directly the server-side logic, in C.
Cheers,
Daniel
Received on 2019-05-22 16:14:27 CEST