svn commit: r1801202 - /subversion/site/publish/faq.html

[ko...@apache.org]

Author: kotkov
Date: Fri Jul  7 18:06:58 2017
New Revision: 1801202

URL: http://svn.apache.org/viewvc?rev=1801202&view=rev
Log:
* site/publish/faq.html
  (shattered-sha1): Tweak this FAQ section to make it a bit more user-
   friendly.  While here, use consistent naming for terms "SHA-1" and
   "deduplication".

Modified:
    subversion/site/publish/faq.html

Modified: subversion/site/publish/faq.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/faq.html?rev=1801202&r1=1801201&r2=1801202&view=diff
==============================================================================
--- subversion/site/publish/faq.html (original)
+++ subversion/site/publish/faq.html Fri Jul  7 18:06:58 2017
@@ -61,8 +61,8 @@ For older questions, see <a href="#depre
     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">&para;</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 in
 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 is 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 -->