Subversion's use of SHA-1 in how it processes content is subject to hashing -collisions as identified by Google. One of -Subversions's key assumptions in processing content is that SHA-1 is unique for -all objects.
-Subversion has two main areas of vulnerability. -Publication of the first known SHA-1 collision by +Google and CWI unveiled a couple of related issues in the Subversion's use +of SHA-1. The Subversion's core does not rely on SHA-1 for content indexing, +but it was being used for such purposes in the following supplementary features: +
-To prevent different content with identical SHA-1 from being stored, upgrade -to 1.9.6 or 1.8.18 which, by default, prevent storing data with such collisions. -See our SHA1 advisory for details. +
Speaking of the repository data deduplication feature, this can result in +inability to access files with colliding SHA-1 values or cause data loss for +such files. To prevent different content with identical SHA-1 from being stored +in a repository, upgrade to 1.9.6 or 1.8.18 which, by default, prevent storing +data with such collisions. See our SHA-1 +advisory for details.
-Until these new releases are available, Unix-based servers can use the pre-commit hook found +Until the upgrade to these new releases is available, Unix-based servers +can use the pre-commit hook found here. As an aside, we welcome Windows developers to submit a pre-commit @@ -777,19 +779,18 @@ script for the Windows platform. More information here.
-The working copy/RA layer uses SHA-1 for de-duplication of content stored in -the working copy, and for performance reasons clients using the HTTP protocol -will avoid fetching content with a SHA-1 checksum which has been fetched -previously. There is no known workaround for this vector except to prevent -storage of the colliding objects in the first place, via upgrade to 1.9.6 or -installation of the aforementioned pre-commit script. +The working copy uses SHA-1 for deduplication of the stored content, and for +performance reasons a client will avoid fetching content with the same SHA-1 +checksum. The workaround for this issue is to prevent storage of the colliding +objects in the first place, via upgrade to 1.9.6 or installation of the +aforementioned pre-commit script.
-Storing content with SHA1 collisions it not a supported use case. If you have -repositories with colliding SHA-1 content, we suggest you transform it via -gzip before committing it to avoid the collision altogether. Moreover an -upgrade to 1.9.6 to prevent future insertion of duplicates is highly -recommended.
+Storing content with SHA-1 collisions it not a supported use case. If you have +content with colliding SHA-1 hash values, we suggest you transform it via gzip +before committing it to avoid the collision altogether. Moreover, an upgrade +to 1.9.6 to prevent future insertion of duplicates is highly recommended. +