Hi all,
I made an attempt to tweak the SHA-1 FAQ entry (which is available at
https://subversion.apache.org/faq#shattered-sha1) to make it a bit more
user-friendly.
Please see the attached patch. What do you think about making a change
like this?
For convenience, here is the final result as plain text:
[[[
How is Subversion affected by SHA-1 hash collisions?
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:
- repository data deduplication feature, and
- content deduplication feature in the working copy.
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 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 script for the Windows platform. More information on
submission can be found here.
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 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.
]]]
Regards,
Evgeny Kotkov
Index: publish/faq.html
===================================================================
--- publish/faq.html (revision 1801149)
+++ publish/faq.html (working copy)
@@ -61,8 +61,8 @@ For older questions, see <a href="#deprecated-faq"
list?</a></li>
<li><a href="#dst-2007">How is Subversion affected by changes
in Daylight Savings Time (DST)?</a></li>
-<li><a href="#shattered-sha1">How do I protect my repository from the SHA-1
- Shattered vulnerability?</a></li>
+<li><a href="#shattered-sha1">How is Subversion affected by SHA-1 hash
+ collisions?</a></li>
</ul>
<h4>How-to:</h4>
@@ -748,28 +748,30 @@ for DST.</p>
<div class="h3" id="shattered-sha1">
<a name="shatterd-sha1"></a><!-- compatibility with an old, misspelled version
of the anchor -->
-<h3>How do I protect my repository from the SHA-1 Shattered vulnerability?
+<h3>How is Subversion affected by SHA-1 hash collisions?
<a class="sectionlink" href="#shattered-sha1"
title="Link to this section">¶</a>
</h3>
-<p>Subversion's use of SHA-1 in how it processes content is subject to hashing
-collisions as identified by <a href="https://shattered.io/";>Google</a>. One of
-Subversions's key assumptions in processing content is that SHA-1 is unique
for
-all objects.</p>
-Subversion has two main areas of vulnerability.
-<br/>
+<p>Publication of the first known SHA-1 collision by <a
href="https://shattered.io/";>
+Google and CWI</a> 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:
+</p>
<ul>
-<li>The FS backend (repository) uses SHA-1.</li>
-<li>The Working Copy/RA layers use SHA-1.</li>
+<li>repository data deduplication feature, and</li>
+<li>content deduplication feature in the working copy.</li>
</ul>
-<p>
-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 <a href="/security/sha1-advisory.txt">SHA1 advisory</a> for details.
+<p>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 <a href="/security/sha1-advisory.txt">SHA-1
+advisory</a> for details.
</p>
<p>
-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
<a
href="https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh";>
here</a>.
As an aside, we welcome Windows developers to submit a pre-commit
@@ -777,19 +779,18 @@ script for the Windows platform. More information
here</a>.
</p>
<p>
-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.
</p>
<p>
-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.</p>
+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.
+</p>
</div> <!-- shattered-sha1 -->
